[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.