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

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Wed, 2011-06-08 at 14:43 +0100, Stefano Stabellini wrote:
> 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.

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.

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

Ian.



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