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

[George Dunlap <george.dunlap@eu.citrix.com>]

On 20/03/13 16:51, Ian Jackson wrote:
> 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 three sets of interfaces we need to consider:
> For disks and networks we offer the same device via both interfaces,
> where available.  I guess we can't do that for USB ?

I don't think the requisite infrastructure is there yet; I suspect that 
usbback needs to have the device assigned to it before it can be made 
available to usbfront, and that this would conflict with qemu having it 
passed through.  Also, there are magic ports the PV front-ends write to 
cause qemu to yank out the emulated block/nic devices before connecting 
to the back-ends -- I don't think such things exist for USB yet.

> If it is actually necessary for the caller to specify, they should
> specify the the protocol by which the device is exposed to the guest,
> not the implementation.
>
> Perhaps we could make the protocol an optional parameter somehow, so
> that if the user just wants "make such-and-such device available",
> they can ask for that and the tools will DTRT ?
>
> Many of your comments relate to differences in the protocols between
> libxl and qemu or backends.  Syntactic differences should IMO be
> hidden by libxl.  There is generally no good reason for semantic
> differences, I think ?

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:

1. Don't expose virtual topology options to the caller.  If using qemu, 
just make the call; if using PVUSB, do what qemu does in automatically 
adding and removing the necessary virtual busses.

2. Expose virtual topology options to the caller.  If using qemu, then 
ignore these / return an error.

3. Add support to qemu for specifying virtual topology.

I don't particularly like either of the first two options.  #1 removes 
the flexibility of the user specifying their own topology for PVUSB, 
even though it's available; #2 make the interface more complicated to 
interact with for HVM.  #3 would be nice, but it's definitely not going 
to happen for 4.3.  (And honestly it's a lot more work than I'm probably 
in for.)

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

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:

1. Force the "namespace" for deletion to be host-device-spec for all 
protocols.

2. Have different ways to delete depending on whether you're PVUSB or qmp.

3. Implement methods for qmp to discover guest virtual topology

I'm not a fan of #1; #2 again suffers from making the interface more 
complicated; and #3 is, I'm guessing, more work than can be done by 4.3.

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.

  -George