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] [PATCH 0/7] merge some xen bits into qemu

To: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/7] merge some xen bits into qemu
From: Gerd Hoffmann <kraxel@xxxxxxxxxx>
Date: Tue, 28 Oct 2008 16:53:07 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, qemu-devel@xxxxxxxxxx
Delivery-date: Tue, 28 Oct 2008 08:54:01 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <18695.8924.513834.478286@xxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1225196622-14164-1-git-send-email-kraxel@xxxxxxxxxx> <18695.8924.513834.478286@xxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.16 (X11/20080723)
Ian Jackson wrote:
> People unfamiliar with the context should note that Gerd's submission
> is NOT `merging some Xen bits into qemu'.  The code that Gerd is
> submitting is VERY SUBSTANTIALLY DIFFERENT from the code which exists
> in the Xen version of qemu.

Yes, as the the intro text says.  You've even quoted the paragraph here:

> Gerd Hoffmann writes ("[Xen-devel] [PATCH 0/7] merge some xen bits into 
> qemu"):
>> The console and framebuffer backend drivers are largely based on the
>> xen code, the other bits are rewritten from scratch.  Nevertheless
>> the code should be functionally identical.
> 
> I'm afraid I'm still opposed to the approach you are taking here.
> 
> The correct route for Xen support for qemu is via qemu-xen-unstable,
> not directly into upstream qemu.

There are *two* patch series for a reason.  The one for upstream qemu,
and the one for qemu-xen.  After applying both patch sets to both threes
they are largely identical.  Anthony indicated that he wants to wait for
the qemu-xen patches being accepted before merging the patches intended
for upstream qemu.  So where exactly is your problem?

> If you want to generalise the backend driver machinery, which in
> qemu-xen-unstable is used only for the framebuffer, you should submit
> your generalised backend machinery on qemu-devel.

Just done.

> qemu-dm is hardly used for paravirtual domains so this is not really
> very helpful.  qemu-dm is not even used at all for most PV domains.

It isn't mandatory.  But every pv domain using the pv framebuffer needs
qemu-dm.  It also can be used to handle the console instead of xenconsoled.

> Command-line differences are not very important in the grand scheme of
> things but they too need to come through xen-devel so that there is a
> sane transition.

As noted in the intro text the qemu-xen patch series don't change the
command line interface.  I think it is easier to hash that out later
separately and not involve xend changes in this patch series.

> For the avoidance of any doubt, Gerd's machine types are for
> _emulating_ a Xen environment on a machine without a real Xen
> hypervisor.

That is one long term goal, yes.  And I want the same backend code being
used for both emulation and xen support.  This patchset is about xen
support only.  There are no emulation bits, they will come later.

> Gerd: Why do I keep having to repeat this point ?  Your messages
> always obscure it.

When submitting xen emulation patches I will clearly state that.

> So in summary: Gerd, please post your suggestions to xen-devel only
> and explain what the purpose of each patch is.

Not involving qemu-devel here is wrong.  Discussing patches for upstream
qemu without involving the relevant people isn't going to work.

Each patch comes with a description of the changes.

> If their intended use is for a system with a real Xen hypervisor and
> xend, and the patches makes sense, then we will of course take them.

They are intended for a system with a Xen hypervisor.
The disk & nic backends need some windup in xend to be usable though.

> In any case, we do not want any huge upheavals in this area that are
> not dealt with appropriately through the Xen testing and release
> processes.  We definitely don't want to have replacements of whole
> swathes of our existing code appear in qemu upstream!

The qemu-xen series is bisectable.  You can take the patches one by one,
run them through the test setup @ XenSource and complain loudly if I
broke something.

cheers,
  Gerd



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