Re: [Xen-devel] [PATCH V4 3/7] libxl: add pvusb API

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

On Tue, Jun 16, 2015 at 11:41 AM, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
>> 3. Have the libxl layer accept both busid and bus:addr.  Translate as
>> necessary and store in the libxl_device_usb struct.
> ...
>> The advantage of #3 internally is that the functions can do the
>> translation once (if necessary), and can then pass around the public
>> libxl_device_usb struct as-is without needing any extra parameters or
>> a separate libxl_device_usb_internal.  The disadvantage, I think, is
>> that from an interface perspective, it's fairly pointless to have
>> both.  busid doesn't really give you any better or more control than
>> the other, and it's not any more convenient for the user (in fact it's
>> less convenient because it's more difficult to find).
>
> Is the busid more stable in the face of plug/unplug ?  This is the
> normal reason for a more path-like device specification.
>
> If so then we must support it, even if it's not the usual way an
> ordinary user would use it for a one-off.  Otherwise you have to write
> something in your config files for the VMs on your VM host, which will
> break when someone plugs a keyboard into the `wrong' USB port.

It's complicated. :-)

The "busid" we're talking about here will identify a device at a
particular *port* in the USB topology; the busid will take whatever is
plugged into that particular port.  So in the example in my other
thread, the Yubikey "busid" is 2-3.1.2; but if I were to unplug the
yubikey and plud my mouse into that port, the mouse would then be at
2-3.1.2.

The "bus:addr" thing that Linux uses assigns a new "addr" every time
you plug in a device.  The first time I plugged in my Yubikey it got
"002:010"; but when I unplugged it and plugged it back in again, it
got "002:011".  I take it this is on purpose, to solve exactly the
problem above -- my mouse was at 2-3.1.2 before, and then I plug in a
USB disk or a smartcard, I want to make sure I don't accidentally send
commands to the wrong device.

The other thing that most programs seem to handle is vendor:deviceid.
The vendor:deviceid is the same every time you plug the device in, no
matter where. The vendorid:deviceid for my Yubikey is "1050:0111"; so
if I put that in my config file for libvirt or qemu, it will pass
through my Yubikey to the VM, no matter where it's plugged in and no
matter how many times it's been plugged in.  Unfortunately,
vendorid:deviceid is not like a MAC address; it's meant to describe
the *type* of device, not be unique to the device itself.  So if you
have multiple devices of the same kind (say, several different
Yubikeys) then vendorid:deviceid can't distinguish which is which.

That's why qemu accepts at both bus:addr and vendorid:deviceid.

We could in theory do the same thing -- accept any subset of {bus,
port, address, vendorid, deviceid} which will uniquely identify a
specific device.  That may actually be a feature as well -- "Pass
through the device at this bus / port, and by the way I expect it to
be a mouse, so don't pass it through if it's something else."

 -George

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