Re: [Qemu-devel] [PATCH 0/7] merge some xen bits into qemu

[Gerd Hoffmann <kraxel@redhat.com>]

Ian Jackson wrote:
> Gerd Hoffmann writes ("[Qemu-devel] [PATCH 0/7] merge some xen bits into qemu"):
>> Here are a bunch of patches which start adding xen support to qemu.
>> Overview (individual patches have longer descriptions):
> 
> Just to clarify: as far as I can tell from the description,
> this code has scant relationship with Xen upstream.

Patches #3 + #4 are largely based on qemu-dm code (as noted in the
individual patch  descriptions).

> I'm generally in favour of pushing functionality out of the Xen branch
> of qemu into upstream.  But going by Gerd Hoffman's description I
> don't think that's what his branch is.  His code doesn't appear to be
> related to the Xen branch of qemu that we are using.

I want to merge the *functionality*.  IMHO that doesn't mean that it
must be the *code* used by Xen at the moment.

> For example,
> 
>> With the first four patches in place upstream qemu can replace xen's
>> qemu-dm for paravirtual domains.  The block and nic backend drivers are
>> full userspace implementations using the grant table device (gntdev).
> 
> we only use qemu-dm in paravirtualised domains for certain marginal
> functions - in many cases it is not used at all.

It's used for xen console (optionally, can also be handled by
xenconsoled) and the virtual framebuffer.

> Certainly the
> functionality Gerd describes, such as xen backend block and network
> drivers, are not in our qemu tree and we do not intend for them to be
> there.

I want them be there though.  You can use them or not, that is your call.

> In a Xen installation this functionality is in the dom0 (host) kernel.

That is only half the story.  The block backend can run in userspace too
(when using blktap).  The block backend driver should be pretty much
identical to blktap functionality-wise.  The implementation is quite
different though.

> As far as I can see much of Gerd Hoffman's intended submission is
> effectively an _emulator_ for Xen guests.  That is, it emulates a Xen
> host without being one, so that a Xen domU can be run without the Xen
> hypervisor.  Am I right, Gerd ?

That is part of the longterm plan, yes.  I want qemu being able to do
both, run as device model for xen and also to boot xen guest images
without xen, using emulation.  If the intention would have been
emulation only I wouldn't have Cc'ed xen-devel for patch review.

The emulation bits are not in that patchset btw.

> But if this functionality is to go into qemu upstream perhaps it
> should be distinguished from `real Xen' functions, because otherwise
> users are going to become very very confused.

Huh?

cheers,
  Gerd

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