[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.