[Xen-devel] Re: [Qemu-devel] [PATCH 13/13] xen: pv domain builder.

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Gerd Hoffmann writes ("[Qemu-devel] [PATCH 13/13] xen: pv domain builder."):
> This adds domain building support for paravirtual domains to qemu.
> This allows booting xen guests directly with qemu, without Xend
> and the management stack.

Gerd Hoffmann writes ("[Qemu-devel] [PATCH 06/13] xen: backend driver core"):
> This patch adds infrastructure for xen backend drivers living in qemu,
> so drivers don't need to implement common stuff on their own.  It's
> mostly xenbus management stuff: some functions to access xentore,
> setting up xenstore watches, callbacks on device discovery and state
> changes, handle event channel, ...

Gerd Hoffmann writes ("[Qemu-devel] [PATCH 11/13] xen: blk & nic configuration 
via cmd line."):
> This patch makes qemu create backend and frontend device entries in
> xenstore for devices configured on the command line.  It will use
> qdisk and qnic backend names, so the qemu internal backends will
> be used.

These kind of patches are rather troublesome I'm afraid.

On one level they are irrelevant to Xen, or at least to Xen upstream.
They exist to support modes of operation which differ from the way
upstream Xen works.  Having other ways to use the Xen hypervisor is
fine by us.  So in theory we shouldn't care.

However in practice these changes are going to make it harder to merge
the existing Xen code, because they do some but not all of the same
things in a different way.  If these patches are merged into qemu
upstream then I'll have to do a lot of untangling.  I might have to
put off bringing our tree up to date again.  (We had ours frozen for a
couple of months for our release.)

What I would prefer is if Gerd would submit a patch or patches to
xen-devel, against our qemu, to factor out of the functionality needed
by his code.  This should be done in a way that is both suitable for
his needs and structurally sensible for the xen upstream tree.

When that patch is accepted into qemu-xen, there will be no trouble
hopefully porting very similar if not entirely identical code into
qemu upstream.  And then Gerd can submit patches to qemu-upstream
for his new backend drivers, and those patches do not need to conflict
with anything in qemu-xen.  Although we ought to review them to make
sure that the command line options, etc., are all clear and
nonconflicting.

Ian.

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