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

Ian.


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