Re: [Xen-devel] [PATCH v2 4/5] libxl: change xs path for pv qemu

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Tue, Jun 09, 2015 at 12:24:35PM +0100, Stefano Stabellini wrote:
> On Tue, 9 Jun 2015, Wei Liu wrote:
> > On Mon, Jun 08, 2015 at 04:27:26PM +0100, Stefano Stabellini wrote:
> > > On Mon, 8 Jun 2015, Wei Liu wrote:
> > > > On Thu, Jun 04, 2015 at 12:28:18PM +0100, Stefano Stabellini wrote:
> > > > > If QEMU is ran just to provide PV backends, change the xenstore path 
> > > > > to
> > > > > /local/domain/0/device-model/$DOMID/pv.
> > > > > 
> > > > > Add a parameter to libxl__device_model_xs_path to distinguish the 
> > > > > device
> > > > > model from the pv backends provider.
> > > > > 
> > > > > Store the device model binary path under
> > > > > /local/domain/$DOMID/device-model on xenstore, so that we can fetch it
> > > > > later and retrieve the list of supported options from
> > > > > /local/domain/0/libxl/$device_model_binary, introduce in the previous
> > > > > path.
> > > > > 
> > > > 
> > > > TBH this protocol works, but it is not very extensible.
> > > > 
> > > > I envisaged we need to assign $emulator_id to different device models
> > > > when I fixed stubdom, but I never got to that since there weren't need
> > > > for multiple emulators.
> > > > 
> > > > That is, as an example:
> > > > 
> > > > /local/domain/$backend_domid/device-model/$domid/$emulator_id/xxx
> > > > 
> > > > That way we can:
> > > > 
> > > > 1. Have something like multidev in libxl to wait for several device
> > > >    models to be ready without writing tedious code for every single one.
> > > > 2. Fit into libxl migration stream, which naturally uses $emulator_id to
> > > >    distinguish different emulators. 
> > > > 
> > > > The downside of this is we need to add an extra option to QEMU to accept
> > > > the emulator id assigned by toolstack.
> > > > 
> > > > Just my two cents.
> > > 
> > > Actually QEMU already retrieves the ioservid by calling
> > > xc_hvm_create_ioreq_server. I could easily use that as id. I am not sure
> > > how I could get that from libxl though, except by assuming that is going
> > > to be 0, because libxl only knows how to create one QEMU emulator.
> > > 
> > 
> > I don't think it's good to use that id directly because as you said
> > there is no way to allocate and get that from libxl. Libxl needs to
> > arrange xenstore directory before QEMU starts up, i.e. before QEMU is
> > able to allocate such id from hypervisor.
> > 
> > Assigning an emulator id would be easy in libxl.
> 
> Adding another option to QEMU is easy. However it is hard to figure out
> which one is the right path from libxl__device_model_xs_path, see:
> 
> char *libxl__device_model_xs_path(libxl__gc *gc, uint32_t dm_domid,
>                                           uint32_t domid, const char
>                                           *format,  ...)
> 
> As you can see from this patch, libxl__device_model_xs_path is called in
> many places. Some of them have very little knowledge about QEMU (see for
> example libxl__toolstack_save and libxl_domain_unpause), so it would be

What libxl_domain_unpause does is to unpause all emulators then unpause
the guest, i.e. it should traverse all emulator ids to unpause them if
necessary. The set of emulator ids can be retrieved from xenstore - a
uniform path can make it easier.

And libxl__toolstack_save proves the need for having emulator ids in
libxl because otherwise you won't know which one is which. It would be
trivial to implement v2 format with my patch.

<1433523702-4540-1-git-send-email-wei.liu2@xxxxxxxxxx>

> difficult to find the right emulator_id, unless we assume that the
> device model is emulator_id=0 and pv qemu emulator_id=1. 

If this is inside libxl level I think it's fine as long as these two ids
are documented as reserved.

Wei.

> 
> 
> > > As there is no ioservid for pv QEMU, I could still use
> > > /local/domain/$backend_domid/device-model/$domid/pv.
> > > 
> > > What do you think?
> > > 
> > 
> > Do you envisage we would need to use several PV qemu? At that point we
> > would face the same problem again. We might as well solve it now.
> 
> Theoretically we could, but in practice is difficult because there is no
> protocol to decide which QEMU process should handle a particular
> backend: all pv QEMU instances would want to handle all PV backends,
> conflicting with each others.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel