[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] QEMU upstreaming: status and todo
On Wednesday 05 January 2011 18:03:15 Stefano Stabellini wrote: > Hi all, > I would like to spent few words to let people know the current status of > the Qemu upstreaming work and what is still missing. > > Anthony Perard sent the 8th version of his "Xen device model support" > patch series to qemu-devel and he has already received an ack from > Alexander Graf. We are currently waiting for another review by Anthony > Liguori but we are positive the series is close to be accepted in its > current form. > > Once the series is upstream we can start using upstream Qemu to do Xen > development, however before we can actually use it as default device > model we need to fill some gaps. > In fact some things are still missing compared to qemu-xen, the > followings in particular: > > - VGA dirty bits optimization > This is a performance optimization for the emulated VGA card, Anthony > Perard is already working on it. > > - switch to SeaBios > Qemu uses SeaBios, that has several advantages on RomBios, one of them > is that SeaBios is actually maintained. > It makes sense to switch from the old Qemu and the old bios to a new > Qemu and a new bios at the same time in order to reduce the > compatibility pains to users. > > - stubdom support > The "Xen device model support" patch series lacks stubdom support. > This is mainly a matter of compiling upstream Qemu against MiniOS, > the problem is that MiniOS is not exactly posix compliant so we'll need > to make some changes. > > - pci passthrough > The patch series also lacks pci passthrough support. > The current pci passthrough code in qemu-xen is rather large and doesn't > integrate very well with the rest of Qemu so it is non-trivial to > upstream. > > - QMP support in libxl > upstream Qemu supports an RPC protocol called QMP that is JSON based. > We need to be able to use it to issue commands to Qemu, replacing the > current mechanism based on xenstore. For example this would be needed by > pci passthrough to send the "plug" and "unplug" commands to Qemu. > > > Ideally we'll be able to complete these tasks by the end of the Xen 4.2 > release cycle so that we can have the new Qemu as default device model > by then. Great job, it sounds really interesting. Is it usable in current state? Can I test it on current xen 4.0.x? Can You write what are the coolest things in upstream qemu? Regards, -- Åukasz OleÅ _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |