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

[Xen-devel] Re: [PATCH] libxl: enabling upstream qemu as pure pv backend

To: Wei Liu <liuw@xxxxxxxxx>
Subject: [Xen-devel] Re: [PATCH] libxl: enabling upstream qemu as pure pv backend.
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Date: Fri, 10 Jun 2011 12:05:36 +0100
Cc: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
Delivery-date: Fri, 10 Jun 2011 04:06:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1307684826.1798.29.camel@limbo>
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> <alpine.DEB.2.00.1106081358210.12963@kaball-desktop> <1307538807.775.737.camel@xxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1106081435470.12963@kaball-desktop> <1307541074.775.739.camel@xxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1106081501020.12963@kaball-desktop> <1307548380.775.744.camel@xxxxxxxxxxxxxxxxxxxxxx> <alpine.DEB.2.00.1106081657380.12963@kaball-desktop> <1307603224.31235.8.camel@limbo> <alpine.DEB.2.00.1106091613480.12963@kaball-desktop> <1307684826.1798.29.camel@limbo>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Alpine 2.00 (DEB 1167 2008-08-23)
On Fri, 10 Jun 2011, Wei Liu wrote:
> > > @@ -702,7 +712,15 @@ retry_transaction:
> > >          if (ret)
> > >              goto out_free;
> > >      }
> > > -    if (libxl__create_xenpv_qemu(gc, domid, vfb, &dm_starting) < 0) {
> > > +
> > > +    memset((void*)&xenpv_dm_info, 0x00, sizeof(libxl_device_model_info));
> > > +    xenpv_dm_info.device_model_version =
> > > +        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
> > > +    xenpv_dm_info.type = LIBXL_DOMAIN_TYPE_PV;
> > > +    xenpv_dm_info.device_model = NULL;
> > > +    if (libxl__create_xenpv_qemu(gc, domid,
> > > +                                 &xenpv_dm_info,
> > > +                                 vfb, &dm_starting) < 0) {
> > >          ret = ERROR_FAIL;
> > >          goto out_free;
> > >      }
> > 
> > You should set device_model_version, type and device_model from the same
> > fields in info, so that the device model version running in the stubdom
> > is the same as the one running in dom0.
> > We don't want to mismatch the two of them.
> > 
> 
> I re-check this part and find that the xenpv_dm_info.type is necessary
> to be hardcoded.
> 
> Things are a bit different in stubdom creation compared to pv creation.
> In pv creation, copying is ok, because there is only one qemu we need to
> pay attention to.
> 
> In fv with stubdom case. There are two qemu's.
> 
> xenpv qemu <--> stubdom (pv) with xenfv qemu <--> hvm domU
> 
> That's the relationship between them.
> 
> To my understanding, the `type` field in dm_info represents which type
> of domain the qemu is supporting.
> 
> The original device model info (which is the `info` passed in
> libxl__create_stubdom) is filled with user config. It represents user's
> domU DM config, which has type LIBXL_DOMAIN_TYPE_FV (supports a fv
> domain), while the xenpv supporting stubdom is expecting type
> LIBXL_DOMAIN_TYPE_PV (stubdom is pv).
> 
> If I directly copy this field from info, libxl__create_xenpv_qemu (which
> calls general creating function libxl__create_device_model) will create
> a FV stubdom.
> 
> And the qemu running in stubdom is hardcoded with '-M xenfv' option in
> libxl_dm.c:libxl__write_dmargs. So I think hardcode `type` is
> acceptable.
> 
> To summarize:
> these two qemu's are by design of two different types.
> copying device_model_version and device_model fields is ok. 

Sorry my mistake. You are absolutely right; just copy
device_model_version and device_model.

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