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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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.

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