qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Xen patches - status summary


From: Anthony Liguori
Subject: Re: [Qemu-devel] Xen patches - status summary
Date: Wed, 03 Sep 2008 21:47:34 -0500
User-agent: Thunderbird 2.0.0.16 (X11/20080723)

Gerd Hoffmann wrote:
Ian Jackson wrote:
I don't know about you but I'm starting to lose track of all the
patches we're submitting from the Xen tree.  So here's a summary of
recent activity:

Patches from Stefano Stabellini awaiting commit to qemu:

 [1/3] vnc dynamic resolution   } minor discussion, all issues resolved
 [2/3] WMVi extension support   }  so should IMO be applied (updated version
 [3/3] vga shared buffer        }  in case of vga shared buffer patch)
 sdl shared buffer support        no discussion, should be applied IMO
 opengl rendering in the sdl ...  no discussion, should be applied IMO

I think they still sitting in anthonys inbox waiting for review ...

Yeah, sorry, I'm on vacation this week and my network access is much worse than I expected it to be. I'm queuing it all up and will go through it this weekend when I get back.

Looking at my git logs here there are quite a few more which will be
forthcoming but perhaps it would be good to digest these first ?

In case you don't know what to do with your time meanwhile:
/me waits for qemu-xen catching up with upstream, so I can update and
respin the patch series ;)

[1] Re: Use fd signal trick to break us out of select
    Re: Introduce #define QEMU_ASYNC_EVENTLOOP

Anthony Ligouri had a different patch based on a helper thread to
provide an emulation of signalfd rather than use of a signal handler.
However (as confirmed by Jamie Lokier) some versions of glibc have
a bug in the handling of the glibc internal aio helper thread(s)
which can make efforts to block signals ineffective.  This means
that Anthony's patch will not work properly on those libcs and as
I wrote already this means that my patch should be applied.

I also tend to dislike os-specific stuff due to the portability issues
it brings.  Sometimes there are good reasons to use it nevertheless.

I haven't made up my mind yet about which approach is better. I'll commit something this weekend though.

The QEMU_ASYNC_EVENTLOOP change is a tidying up of the NBD feature to
make qemu-nbd share more commonality with qemu-img.  As discussed
there are perhaps even more cleanups that could be done to improve
this but as I say this change is a good start and should be applied.

Cleanups is, well, not the correct word IMHO.  The complete block device
handling needs a major redesign.  That this ifdef is needed in the first
place is a blatant layering violation.  Also we should be able to
support async I/O in some form (be it libaio, threads or whatever)
without hacking support for it into each and every file format handler.

I have something queued up to help us get closer to this.

[3] Re: IDE error checking

Yep, this certainly needs to be fixed.
/me votes for applying them, although I don't know IDE good enougth to
comment on the patches themself.

I think I explained what I didn't like about this patch--that all IO errors were being reported to the guest as ECC errors. I don't feel this is correct, in particular for ENOSPC. When ENOSPC occurs, the guest is likely to really mess itself up. Since ENOSPC is almost certainly going to be the most common error, it needs to be handled specially.

Regards,

Anthony Liguori

cheers,
  Gerd









reply via email to

[Prev in Thread] Current Thread [Next in Thread]