Re: [Xen-devel] [PATCH RFC] libxl: Introduce functions to add and remove USB devices to an HVM guest

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

George Dunlap writes ("Re: [Xen-devel] [PATCH RFC] libxl: Introduce functions 
to add and remove USB devices to an HVM guest"):
> The reason for specifying STUBDOM I guess is that STUBDOM is really a 
> special case, where it's really both a PVUSB  and a DEVICEMODEL; so in 
> theory you could specify a backend_domid.

I think in principle you could specify a backend domid for a non-stub
dm too.

> The question, I guess, is whether we should assume that the caller can 
> be trusted to know whether the VM in question is using a stub domain or 
> not.  It's certainly possible to make the interface only specify PVUSB 
> or DEVICEMODEL, and to make it (someday) so that calling DEVICEMODEL for 
> a stubdom will set up PVUSB for the stubdom, then tell the device model 
> to make the device available via emulation all automatically.

libxl can tell whether the guest is using a stub-dm.

> But since we're not implementing stubdom at the moment anyway, we can 
> probably just take out STUBDOM entirely and discuss whether to add a new 
> protocol when we actually decide to implement it.

It affects the documentation now, I thinki.

> > What are the semantics if multiple host devices match *dev ?
> > How is the id returned ?
> 
> I think in general if it matches multiple devices then it should fail.  
> That's what qemu will do, so at the moment that is implemented by 
> default for us.

This should be documented.

> > I think dev should probably be
> >    const libxl_device_usb *dev
> 
> Sure.

You didn't ask my question about ids.

> > This is a lot of enum-handling machinery.  Don't we have something
> > similar already which could be pressed into service ?  If not then
> > this should be in a separate file.
...
> > Perhaps this should be generated by the idl compiler ?\
> 
> I'm not going to be able to make that happen by the feature freeze this 
> Friday.
> 
> Perhaps just writing the raw numeric values for now?

If it's just needed for xenstore for the toolstack's own consumption
then that's fine, as when you upgrade the toolstack you need to
upgrade xen and thus migrate away all your domains.  Alternatively I
think the IDL compiler produces long names which might be useable too.

> > I stopped reading here because of the wrap damage I'm afraid.
> > (Reproduced it by adding hard CRs where my MUA wraps it, so you can
> > see what it looks like.)
> 
> Well the main purpose of this mail was to see if this could be 
> implemented by Friday, or if it would need to wait until 4.4.  We've 
> uncovered a couple of things which if required would mean waiting -- 
> what do you think?  I'm fine with waiting -- that's why I sent the 
> e-mail, so I could stop early if there was little chance of success. :-)

I don't think my questions need to be answered in a way that means we
have to wait, so long as we have a route to improving things later.

Ian.

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