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

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Wed, 2011-06-08 at 16:51 +0100, Stefano Stabellini wrote:
> On Wed, 8 Jun 2011, Ian Campbell wrote:
> > Shouldn't the vfb stuff come from the libxl_domain_info (is it c_ or b_
> > I forget) not the dm_info info? It's really a property of the guest not
> > the device model.
> 
> yeah, good point
> 
> 
> > > But if we do this we have to be careful because in the stubdom case the
> > > libxl_device_model_info that we pass to libxl__create_xenpv_qemu is NOT
> > > the same used to build the stubdom.
> > > The info parameter passed to libxl__create_stubdom is the
> > > libxl_device_model_info that describes the stub qemu-for-FV.
> > > While the info parameter that we pass to libxl__create_xenpv_qemu is the
> > > libxl_device_model_info that describes the qemu-for-PV in dom0.
> > 
> > Right, my suggestion was that they potentially _could_ be the same, with
> > the two functions doinging the right thing internally. This would avoid
> > the need to figure out which params need to be copied from the user
> > supplied struct to the xenpv one -- they would simply be the same.
> > 
> 
> Ideally the vnc and sdl proprieties of a vfb should be moved into
> the corresponding fields of device_model_info, because they are not
> specific to the vfb protocol, rather a configuration of the backend
> (qemu).
> This way we wouldn't need libxl__build_xenpv_qemu_args anymore.
> 
> I wouldn't use the same device_model_info instance for both qemu-FV and
> qemu-PV in the stubdom case, I would rather keep them separate.

OK, then we either need a way to configure both (dupping the options) or
one needs to be derived from the other in some useful way...

Ian.



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