[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: xenconsoled CPU denial of service problem
On 4/10/06 18:19, "Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: >> Considering that today in Xen we have a default buffer size, it seems >> considerably easier to me to just get rid of xenconsoled completely and >> expand the domU-kernel ring queue to be the actual size of what we're >> buffering today. >> >> This eliminates all of these problems and gets rid of a dom0 daemon. >> Plus, the domU gets taxed for the buffer memory instead of dom0. >> >> We would then change xenconsole to read the buffer directly. > > Its very useful to be able to expose the data as a Psuedo-TTY, as > it lets people use standard toolset for dealing the DomU log data. > eg virt-manager can just connect up a VTE terminal widget straight > to the TTY for a terminal UI. Or tools like ttywatch can log the > data to file, or network, etc. Or minicom for a standard text based > interactive client, etc Forcing everything to use the custom > xenconsole client program would be a step backward. There's also the issue of backward compatibility with guests with a small inter-domain ring. And this doesn't solve the fundamental problem of dom0 getting slammed with lots of event-channel notification. We need rate limiting anyhow, on all our inter-domain comms channels. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |