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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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