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/
Home Products Support Community News


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

Samuel Thibault wrote:
> Samuel Thibault, le Tue 05 Aug 2008 16:03:28 +0100, a écrit :
>> Gerd Hoffmann, le Tue 05 Aug 2008 15:18:46 +0200, a écrit :
>>> Samuel Thibault wrote:
>>>> Then it'd probably be good to push that upstream Xen.
>>> I'm cross-posting the patches to xen-devel for a reason.
>> Well, cross-posting qemu patches to xen-devel is not the same as posting
>> xen patches to xen-devel...
> Just to explain a bit more, now that I have read the patches a bit: what
> is there is somehow far from the xen unstable tree, at least because
> of the backend driver core, and because of other 'details' (renaming,
> moving).  I doubt Ian will be happy to have to make the effort to merge
> that in his tree and I guess he will probably just drop everything and
> keep the xen-unstable version.

Sure, merging stuff upstream involves alot of work short-term, you'll
get the benefits long-term.

pv domain support is easy, as this is largely self-contained.  hvm will
be even more work, because hvm support is much more invasive and on top
of that the qemu interfaces will change to nicely support the various
ways to run code natively instead of emulated (kqemu, kvm, xen).

The rough way to merge would look like this:

  - drop xen_console.[ch]
  - drop xenfb.[ch]
  - drop xen_machine_pv.c

  - add xen.h
  - add xen-machine.c
  - add xen-backend.[ch]
  - add xen-console.c
  - add xen-framebuffer.c

  - wind up stuff in the Makefiles.
  - some global renames (domid -> xen_domid for example) as I took care
    to prefix global xen variables & functions with xen_.
  - probably some small fixups are needed ...

You probably wouldn't do that before the 3.3 (4.0?) release.  If you
keep the xenish vl.c version the differences between upstream qemu and
qemu-dm command line options and vnc handling go away.  The you can
gradually move qemu-dm to be more upstream-ish while also updating xend

Note that qemu-dm has a few optimizations in the qemu display code to
avoid unneeded work.  I'd suggest to submit them upstream.  The we can
enable the bits in xen-framebuffer.c which make use of them.
DisplayState->idle for example.



Xen-devel mailing list

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