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: [PATCH] libxl: enabling upstream qemu as pure pv bac

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] libxl: enabling upstream qemu as pure pv backend.
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Wed, 8 Jun 2011 14:00:21 +0100
Cc: Wei Liu <liuw@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Wed, 08 Jun 2011 05:58:31 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1307536033.775.732.camel@xxxxxxxxxxxxxxxxxxxxxx>
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: <1307503152.31359.2.camel@limbo> <alpine.DEB.2.00.1106081222390.12963@kaball-desktop> <1307536033.775.732.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Wed, 8 Jun 2011, Ian Campbell wrote:
> > I don't think is a good idea to reset all these value to 0 here,
> > considering that the info parameter can be passed by the user.
> > It is better to use another libxl_device_model_info local variable and
> > just copy the very few fields we care about.
> > Otherwise in the stubdom case above you'll have the unwanted side effect
> > of removing useful informations of the stubdom from the structure.
> I think ideally the struct would be the same for both the PV and FV qemu
> and the device model create would only pay attention to the bits which
> fit the scenario (i.e. the PV case would ignore vcpus != 0, not zero
> it).
> This allows us to pass the same instance to both the PV and FV arg
> constructions routines in the stubdom+PV qemu case.

I wouldn't be opposed to it.
The reason I didn't suggest to make this change now is that I see a
certain argument to keep the vfb settings separate, considering that vfb
can be thought as implementation independent protocol.

Xen-devel mailing list

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