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] 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

<Prev in Thread] Current Thread [Next in Thread>