[Xen-devel] Re: xenconsoled CPU denial of service problem

[Anthony Liguori <aliguori@xxxxxxxxxx>]

Daniel P. Berrange wrote:
> On Wed, Oct 04, 2006 at 11:49:56AM -0500, Anthony Liguori 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.
>   
Xenconsole could still spit out on a PTY.  You don't necessarily need a 
daemon though (you could launch a xenconsole for each domain that was 
started).
That also gives you a bit more choice in how you expose the console (you 
could have a xenconsole that spit out via TCP).
Furthermore, we don't have to break guest compatibility.  Older guests 
just have a very small buffer.
It doesn't solve the event channel storming..  Maybe that's something to 
do in the hypervisor?
Regards,

Anthony Liguori

> Dan.
>   

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel