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:
> On Wed, 2011-06-08 at 14:00 +0100, Stefano Stabellini wrote:
> > On Wed, 8 Jun 2011, Ian Campbell wrote:
> > > > I don't think is a good idea to reset all these value to 0 here,
> > > > considering that the info parameter can be passed by the user.
> > > > It is better to use another libxl_device_model_info local variable and
> > > > just copy the very few fields we care about.
> > > > Otherwise in the stubdom case above you'll have the unwanted side effect
> > > > of removing useful informations of the stubdom from the structure.
> > > 
> > > I think ideally the struct would be the same for both the PV and FV qemu
> > > and the device model create would only pay attention to the bits which
> > > fit the scenario (i.e. the PV case would ignore vcpus != 0, not zero
> > > it).
> > > 
> > > This allows us to pass the same instance to both the PV and FV arg
> > > constructions routines in the stubdom+PV qemu case.
> > 
> > I wouldn't be opposed to it.
> > The reason I didn't suggest to make this change now is that I see a
> > certain argument to keep the vfb settings separate, considering that vfb
> > can be thought as implementation independent protocol.
> 
> Hmm, that's an interesting case, but I think:
> 
> if qemu-for-PV guest:
>       vfb args -> xenpv qemu (no brainer, it's the only one)
> if non-stub qemu-for-FV guest:
>       vfb args -> xenfv qemu (no brainer, it's the only one)
> if stub qemu-for-FV guest:
>       vfb args -> xenpv qemu process (what the user connects to)
>       do the right thing internally args -> xenfv in stub domain
> 
> IOW in the stub case the args for the stub FV qemu are an implementation
> detail within libxl.
 
I agree.
However I meant that one day we could have a vfb implementation that is
not in Qemu. However this reason alone doesn't prevent us from adding a
libxl_device_vfb to libxl_device_model_info.
So I guess we could remove the vfb parameter from
libxl__create_xenpv_qemu and embed it into libxl_device_model_info.

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.

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