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


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

To: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>, Gerd Hoffmann <kraxel@xxxxxxxxxx>, Markus Armbruster <armbru@xxxxxxxxxx>, Anthony Liguori <anthony@xxxxxxxxxxxxx>, qemu-devel@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 0/7] merge some xen bits into qemu
From: Gerd Hoffmann <kraxel@xxxxxxxxxx>
Date: Thu, 07 Aug 2008 09:33:06 +0200
Delivery-date: Thu, 07 Aug 2008 00:33:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20080806221047.GE4486@implementation>
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: <20080805150328.GT4478@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080805154140.GV4478@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <48997981.1030703@xxxxxxxxxx> <20080806102338.GA4448@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <m37iauxqii.fsf@xxxxxxxxxxxxxxxxxxxxx> <20080806125055.GG4448@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4899AD19.8060606@xxxxxxxxxx> <20080806140132.GL4448@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4899B06F.2090101@xxxxxxxxxx> <20080806142526.GN4448@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20080806221047.GE4486@implementation>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20080501)
Samuel Thibault wrote:
> Samuel Thibault, le Wed 06 Aug 2008 15:25:26 +0100, a écrit :
>> Pushing the cleaning changes to Xen first can be done and would entail
>> much easier to tackle breakage, and the merge back from qemu would then
>> be trivial, why not doing so?
> You didn't answer that part.  Really, my only concern is about having
> things tested.  Isn't it possible for instance to just merge the backend
> core (and console/xenfb updates) in Ian's tree first for a start?


I didn't touch the build system, it is even more scary than the qemu one
alone, I just set CONFIG_XEN unconditionally.

I also largely left vl.c as-is, so xend shouldn't need any changes.  The
-domid switch sets an additional (redundant) variable, to keep the
amount of changes as small as possible for now.  Also -name and
-domain-name are aliased, both set qemu_name and domain_name.

In upstream qemu xenpv support is a runtime-switch for the normal qemu,
the xen patches leave the qemu-dm target in place.

The framebuffer driver probably has some performance regressions.
Fixing those depends on the display patches being pushed upstream.

> Then you can push your code to qemu,
> I guess that could be fine, as you said xen will not need to use e.g.
> the block and net backends.

blk and net backends are not there (yet).  But they should be a nop for
xen anyway as long as you don't wind up stuff in xend to put them in
use.  For the net backend it probably wouldn't be that useful.  The
block backend should be a good replacement for blktap though and maybe
can save you the effort of porting the blktap kernel driver to the
pv_ops kernel.



Xen-devel mailing list

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