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

Re: [Xen-devel] Re: [PATCH] qemu-xen: Fix PV segfault



Ian Jackson wrote:
> Gerd Hoffman's tree seems to be something entirely different.  I'm not
> sure I understand what the point of it is.  The reason why everyone is
> using qemu is that it has all of the hardware emulation device models.

And everybody is forking qemu for that which is bad.

If some security issue shows up distros have to update tons of packages,
each with a copy of qemu, to name only one problem with that.

> Qemu proper (ie upstream) also uses the CPU emulator (translator,
> now).  KVM and Xen don't use that because they run the code on the
> physical CPU one way or another.

Yep.

> Gerd Hoffman's setup doesn't use the device models, nor the CPU
> emulator.  Really as far as I can tell the only thing he wants from
> qemu is the command line parser !  This is quite bizarre as it's not a
> very good command line parser (qemu upstream are considering replacing
> it with something more data-driven and more modular).

If you start a pv guest with a paravirt framebuffer a qemu-dm process in
dom0 will handle the framebuffer backend and the vnc server.  I want
those bits being merged into upstream qemu, so upstream qemu is able to
do that too.

At very minimum I want those parts needed by xenner in upstream qemu,
which is just the pv bits.  Merging all the hvm stuff too and thereby
making the qemu-dm fork obsolete would be cool too.

cheers,
  Gerd

-- 
http://kraxel.fedorapeople.org/xenner/

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.