From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH V4 3/7] libxl: add pvusb API Date: Tue, 16 Jun 2015 12:01:25 +0100 Message-ID: References: <1433906441-3280-1-git-send-email-cyliu@suse.com> <1433906441-3280-4-git-send-email-cyliu@suse.com> <21887.64856.265751.921367@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21887.64856.265751.921367@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: Wei Liu , Ian Campbell , Chunyan Liu , "xen-devel@lists.xen.org" , Jim Fehlig , Simon Cao List-Id: xen-devel@lists.xenproject.org On Tue, Jun 16, 2015 at 11:41 AM, Ian Jackson 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