[Xen-devel] Proposed plan for libxl USB interface (was Re: [PATCH V4 3/7] libxl: add pvusb API)

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 06/18/2015 01:08 PM, George Dunlap wrote:
> This usb interface stuff is really becoming a morass.  The core
> functionality is fairly independent of the interface.  I'm inclined to
> say that we should start with a simple specification (only bus.addr),
> and try to get both pvusb and hvmusb in.  Then we can talk about where
> to add additional specifications (including cross-boot stable
> specifcations).

So Ian J, Ian C, Wei and I chatted face-to-face about what to do going
forward; below are some key points we discussed and the conclusion we
came to.  Decisions are only official when they've been discussed on the
list, so please consider this a proposal and give your feedback. :-)

(Also, Ian/Ian/Wei, let me know if I've misremembered or forgotten
something.)

Points of discussion:

* We would ideally like to be able to have the released interface work
both for both PV and HVM; for one so that we don't have to have separate
#defines for that functionality; but also to make sure that the
interface is suitable for both functionalities.

* It's difficult at the moment to actually do collaborative development
on the libxl USB feature, because the code is not yet in the tree.

* Regarding user-facing interfaces (like xl, as opposed to libxl): the
interface cannot be half-baked; it should not provide functionality
which works most of the time but sometimes will fail.

Having only "bus-ports" or "vendorid:deviceid" is not sufficient,
because it will lure the user into thinking that they can put those
numbers into a config file and get repeatable results every time.  But
since bus numbers change, and vendorid:deviceid is not unique, either of
these would be a false promise.

Udevs ID_PATH naming scheme seems like a sensible thing to adopt, at
least for Linux.  We could consider making an OS-specific string for
identifying the same device across reboots.

On the other hand, bus.address is very obviously unstable; nobody in
their right mind would use it for anything they wanted to persist across
reboots.  So including bus.address as a temporary measure to be able to
test the underlying library until we get a more reliable naming scheme
in place would be OK, as long as the UI interface could be extended
going forward.

* We should avoid adding complexity to the libxl interface until it's
needed; accepting one way of specifying USB devices, and letting the
toolstack do translation into that way of specifying it (perhaps
providing helper libraries to do so), should be enough for now.  The way
of specifying USB devices does not need to be stable across reboots, as
long as it won't change between the time the toolstack does the
translation and the time the device is plugged in.

bus.address is the best specification from that point of view: it's
unique (unlike device:vendorid), and if a device is unplugged and
another one plugged in between the time the translation happens and the
time libxl gets around to doing something, the old bus.address won't
exist anymore and the command will fail.

* There may be a point in the future when we want to be able provide
device auto-plug functionality at the libxl layer.  (i.e., "When device
X shows up, please plug it into VM Y.")  For this we will need a
reliable way of specifying devices; bus.address will not do.

But that functionality doesn't exist yet; so for now we should stick
with bus.address, but design the interface such that it can be extended
with more options for specifying a device when such functionality is neede.

With all that in mind, here is a proposal:

1. For the moment, only use bus.address at the libxl layer to specify a
device.

2. Let's check in the libxl part of Chunyan's PVUSB series as soon as
the 4.7 development window opens (assuming the coding style issues have
all been addressed).  We can also check in the xl functionality with
minimal bus.address support for testing.

3. I will the port the HVM USB series and submit them as soon as possible.

4. We work on a set of helper functions that a toolstack can use to
translate other ways of specifying a device, much like the disk
specification helper functions that we provide.  One of these should be
something which is reliably stable over reboots, such as the udev
ID_PATH specification.

Thoughts?

 -George

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