WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH 5 of 9] libxl: only use interactive PyGrub mode w

On Mon, 2011-10-10 at 15:51 +0100, Roger Pau Monné wrote:
> > That sounds unfortunate.  I agree with you.
> 
> Well Ian Campbell proposed to use a timeout in select and drop data
> when the timeout is hit, that what I've implemented in
> 
> libxl: drop bootloader output if xenconsole file descriptor is not
> available for writing
> 
> The patch is quite simple and solves the problem, I don't think it
> interferes with normal boot process, since a 1s timeout is quite high
> for data to be delivered from xenconsoled_fd to the user if the
> console is attached.

The case where a user types
        xl create /a/domain
        xl console adomain

might have a reasonably long delay in it before the console is
connected. Increasing the libxl buffer size would mitigate that but
you'd still have the problem of not reading from an fd if the cons is !=
0.

Can you print out the actual values of the various producers and
consumers at the point of the hang? (maybe track total bytes too for
debug?)

Perhaps where we have:
        if (xenconsoled_prod == xenconsoled_cons)
            xenconsoled_prod = xenconsoled_cons = 0;
        if (bootloader_prod == bootloader_cons)
            bootloader_prod = bootloader_cons = 0;
We could also add some suitable memmoves and associated prod/cons
manipulation, such that the unconsumed data is always pulled to the head
of the buffer. That might be a reasonably simple way to improve things
and allow larger buffers to be used? More often than not the memmove
won't be getting called since either XXX_prod == XXX_cons or XXX_cons is
already 0, IOW having a partially consumed buffer would be unusual?

Once we have a larger buffer which we always try to fill discarding data
after a timeout when the buffer is full won't be so critical.

>  The other option would be to modify xenconsole
> daemon, but I think that's far too complicated for a problem that can
> be solved easily.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



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