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

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
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

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