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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

George Dunlap writes ("Re: [Xen-devel] [PATCH 1/2] libxl: Introduce functions 
to add and remove host USB devices to an HVM guest"):
> There are some semantic differences that I think are important (or could 
> be important).  One big one is that PVUSB appears to require the caller 
> to specify the virtual topology used, while with qemu it is not possible 
> to specify the virtual topology.  This gives us a few options for a 
> unified interface:

The obvious answer to this is to make specifying the virtual topology
optional in the unified syntax.

(TBH I'm not sure why anyone would ever want to specify a particular
virtual topology.  I'm sure most people would prefer just to let the
tools set something up.)

> PVUSB also (it seems) requires devices to be assigned to usbback before 
> they can be given to guests.  So in the pv case, device_add() would have 
> to do assign then attach, and device_del would have to do detach then 
> de-assign.  That's probably not so bad.

I definitely think this should happen automatically.

> I'm guessing that PVUSB requires you to specify devices by 
> hostbus.hostaddr, not by productid:vendorid.  Having a unified interface 
> would probably mean only allowing any device to be specified by 
> hostbus.hostaddr.  This is technically a masking of the functionality of 
> qmp (namely, the ability to specify by vendorid.productid), but that's 
> probably not a terrible loss.

Well, it would involve that, or implemnting some kind of search
facility so that the host path is looked up appropriately.  Clearly a
reasonable interface would allow the user to specify the device either
way.

> Another difference is that PVUSB (and qemu-traditional) remove devices 
> by the guest virtual topology, while qmp must remove them using the id 
> assigned when setting it up.  However, there is no way to tell when 
> calling device_add what the virtual topology will end up looking like, 
> and no way to query it from outside of the guest once it's done.  So it 
> seems the options would be:

You've missed

 4. Maintain in the toolstack whatever information is necessary to do
    device listing and removal.

> Another aspect of all this is that it would be nice, at some point in 
> the future, to expose more of the qdev interface.  qdev allows you to 
> plug in virtual USB sticks, and a whole range of emulated devices.
> 
> And, having a unified interface would more or less force me to actually 
> implement the PVUSB interface by 4.3, to make sure that the interface 
> can be properly implemented, and that we haven't missed anything.

I think the right approach is to think what interface we want,
implement the subset of it we care about and have time for right now,
and declare failure to support this interface by other implementations
a bug.  I don't think there are any aspects of a plausible and sane
interface that are in principle excluded by any of the
implementations.

Ian.

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