Re: [Xen-devel] [PATCH v10 0/5] xen pvusb toolstack work

["Chun Yan Liu" <cyliu@xxxxxxxx>]

>>> On 12/10/2015 at 08:05 PM, in message
<1449749113-1243-1-git-send-email-george.dunlap@xxxxxxxxxxxxx>, George Dunlap
<george.dunlap@xxxxxxxxxxxxx> wrote: 
> Chunyan, 
>  
> I did a thorough review of v3, and almost all the comments I had fell 
> into two categories: 
>  
> 1. Trivial things that could be easily fixed 
>  
> 2. Complicated things that would be difficult to explain and might 
> take several rounds to correct. 
>  
> As such, I hope you don't mind that I took the liberty to simply fix 
> up the series the way I thought it should be.  I've only 
> compile-tested this; if you could review it, and test it (and if 

Sure, I will. Thank you a lot!

- Chunyan

> necessary give more feedback), and then either ack it or revise and 
> re-send it, I'd appreciate it. 
>  
>  -George 
>  
> Below is Chunyan's original pvusb cover letter. 
>  
> --- 
> This patch series is to add pvusb toolstack work, supporting hot add|remove 
> USB device to|from guest and specify USB device in domain configuration  
> file. 
>  
> Changes to V9: 
> * Rebased to staging (ec0712576198633dd7fbfe25290b030d5a23b252) 
> * Lots of changes to patch 3/5 
> * Removed patches related to "list-assignable-devices" functionality 
>  
>               <<< pvusb work introduction >>> 
>  
> 1. Overview 
>  
> There are two general methods for passing through individual host 
> devices to a guest. The first is via an emulated USB device 
> controller; the second is PVUSB. 
>  
> Additionally, there are two ways to add USB devices to a guest: via 
> the config file at domain creation time, and via hot-plug while the VM 
> is running. 
>  
> * Emulated USB 
>  
> In emulated USB, the device model (qemu) presents an emulated USB 
> controller to the guest. The device model process then grabs control 
> of the device from domain 0 and and passes the USB commands between 
> the guest OS and the host USB device. 
>  
> This method is only available to HVM domains, and is not available for 
> domains running with device model stubdomains. 
>  
> * PVUSB 
>  
> PVUSB uses a paravirtialized front-end/back-end interface, similar to 
> the traditional Xen PV network and disk protocols. In order to use 
> PVUSB, you need usbfront in your guest OS, and usbback in dom0 (or 
> your USB driver domain). 
>  
> 2. Specifying a host USB device 
>  
> QEMU qmp commands allows USB devices to be specified either by their 
> bus address (in the form bus.device) or their device tag (in the form 
> vendorid:deviceid). 
>  
> Each way of specifying has its advantages: 
>  
>     Specifying by device tag will always get the same device, 
> regardless of where the device ends up in the USB bus topology. 
> However, if there are two identical devices, it will not allow you to 
> specify which one. 
>  
>     Specifying by bus address will always allow you to choose a 
> specific device, even if you have duplicates. However, the bus address 
> may change depending on which port you plugged the device into, and 
> possibly also after a reboot. 
>  
> To avoid duplication of vendorid:deviceid, we'll use bus address to 
> specify host USB device in xl toolstack. 
>  
> You can use lsusb to list the USB devices on the system: 
>  
> Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 
> Hub 
> Bus 003 Device 002: ID f617:0905 
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub 
> Bus 001 Device 004: ID 0424:2640 Standard Microsystems Corp. USB 2.0 
> Hub 
> Bus 001 Device 005: ID 0424:4060 Standard Microsystems Corp. Ultra 
> Fast Media Reader 
> Bus 001 Device 006: ID 046d:c016 Logitech, Inc. Optical Wheel Mouse 
>  
> To pass through the Logitec mouse, for instance, you could specify 
> 1.6 (remove leading zeroes). 
>  
> Note: USB hubs can not be assigned to guest. 
>  
> 3. PVUSB toolstack 
>  
> * Specify USB device in xl config file 
>  
> You can just specify usb devices, like: 
> usbdev=['1.6'] 
>  
> Then it will create a USB controller automatically and attach the USB 
> device to the first available USB controller:port. 
>  
> or, you can explicitly specify usb controllers and usb devices, like: 
> usbctrl=['verison=1, ports=4', 'version=2, ports=8', ] 
> usbdev=['1.6, controller=0, port=1'] 
>  
> Then it will create two USB controllers as you specified. 
> And if controller and port are specified in usb config, then it will 
> attach the USB device to that controller:port. About the controller 
> and port value: 
> Each USB controller has a index (or called devid) based on 0. The 1st 
> controller has index 0, the 2nd controller has index 1, ... 
> Under controller, each port has a port number based on 1. In above 
> configuration, the 1st controller will have port 1,2,3,4. 
>  
> * Hot-Plug USB device 
>  
> To attach a USB device, you should first create a USB controller. 
> e.g. 
> xl usb-ctrl-attach domain [version=1|2] [ports=value] 
> By default, it will create a USB2.0 controller with 8 ports. 
>  
> Then you could attach a USB device. 
> e.g. 
> xl usb-attach domain 1.6 [controller=index port=number] 
> By default, it will find the 1st available controller:port to attach 
> the USB device. 
>  
> You could view USB device status of the domain by usb-list. 
> e.g. 
> xl usb-list domain 
> It will list USB controllers and USB devices under each controller. 
>  
> You could detach a USB device with usb-detach command. 
> e.g. 
> xl usb-detach domain 1.6 
>  
> You can also remove the whole USB controller by usb-ctrl-detach 
> command. 
> e.g. 
> xl usb-ctrl-detach domain 0 
> It will remove the USB controller with index 0 and all USB devices 
> under it. 
>  
> 4. PVUSB Libxl implementation 
>  
> * usb-ctrl-attach 
> To create a usb controller, we need: 
> 1) generate usb controler related information 
> 2) write usb controller frontend/backend info to xenstore 
> PVUSB frontend and backend driver will probe xenstore paths and build 
> connection between frontend and backend. 
>  
> * usb-ctrl-detach 
> To remove a usb controller, we need: 
> 1) check if the usb controller exists or not 
> 2) remove all usb devices under controller 
> 3) remove usb controller info from xenstore 
>  
> * usb-attach 
> To attach a usb device, we need: 
> 1) check if the usb device type is assignable 
> 2) check if the usb device is already assigned to a domain 
> 3) add 'busid' of the usb device to xenstore contoller/port/. 
>    PVUSB driver watches the xenstore changes and detects that, 
>    and needs to use 'busid' to do following work. 
> 4) unbind usb device from original driver and bind to usbback. 
>    If usb device has many interfaces, then: 
>    - unbind each interface from its original driver and bind to usbback. 
>    - store the original driver to xenstore for later rebinding when 
>      detaching the device. 
>  
> * usb-detach 
> To detach a usb device, we need: 
> 1) check if the usb device is assigned to the domain 
> 2) remove the usb device from xenstore controller/port. 
> 3) unbind usb device from usbback and rebind to its original driver. 
>    If usb device has many interfaces, do it to each interface. 
>  
> * usb-list 
> List all USB controllers and USB devices under each controller. 
>  
> 5. PVUSB xenstore information 
>  
> PVUSB xenstore information includes three parts: frontend, backend 
> and /libxl part. 
>  
> A USB controller is corresponding to a "vusb" device in xenstore. 
> Adding a USB controller will add a new "vusb" device, removing a 
> USB controller will delete the related "vusb" device. 
>  
> Following is an example xenstore values of a USB controller. 
> Backend: 
>    backend = "" 
>     vusb = "" 
>      1 = "" 
>       0 = "" 
>        frontend = "/local/domain/1/device/vusb/0" 
>        frontend-id = "1" 
>        online = "1" 
>        state = "4" 
>        type = "pv" 
>        usb-ver = "1" 
>        num-ports = "4" 
>        port = "" 
>         1 = "" 
>         2 = "" 
>         3 = "" 
>         4 = "" 
>  
> Frontend: 
>    device = "" 
>     vusb = "" 
>      0 = "" 
>       backend = "/local/domain/0/backend/vusb/1/0" 
>       backend-id = "0" 
>       state = "4" 
>       urb-ring-ref = "348" 
>       conn-ring-ref = "346" 
>       event-channel = "20" 
>  
> Adding a USB device won't create a new "vusb" device, but only write 
> the USB device busid to one port of USB controller. 
> For example, attaching a USB device (busid is 2-1.6) to above USB 
> controller port 1, it only need write 2-1.6 to port 1 of this USB 
> controller: 
> Backend: 
>    backend = "" 
>     vusb = "" 
>      1 = "" 
>       0 = "" 
>        frontend = "/local/domain/1/device/vusb/0" 
>        frontend-id = "1" 
>        online = "1" 
>        state = "4" 
>        type = "pv" 
>        usb-ver = "1" 
>        num-ports = "4" 
>        port = "" 
>         1 = "2-1.6" 
>         2 = "" 
>         3 = "" 
>         4 = "" 
> Frontend doesn't change. 
>  
> Since assign a host USB device to guest, we'll unbind USB interfaces 
> from their original drivers and bind them to usbback. After detaching 
> this USB device from guest, one would hope the USB interfaces could 
> be rebind to their original drivers, so there should some place to 
> get the original driver info. To support that, when attaching a USB 
> device to guest, we'll save the original driver info in xenstore too, 
> the place is /libxl/usbback, for example: 
> libxl = "" 
>  1 = "" 
>   dm-version = "qemu_xen" 
>  usbback = "" 
>   3-11 = "" 
>    3-11@1_0 = "" 
>     driver_path = "/sys/bus/usb/drivers/btusb" 
>  
> In this example, USB device (busid is 3-11, /sys/bus/usb/devices/3-11). 
> It has interface 3-11:1.0, whose original dirver is btusb. 
> Since xenstore doesn't allow ':' and '.' in a key, so we encode the 
> interface by changing ':' to '@' and changing '.' to '_'. 
>  
> When detaching the USB device from guest, we can rebind 3-11:1.0 to 
> btusb driver. 
> --- 
> CC: Ian Campbell <ian.campbell@xxxxxxxxxx> 
> CC: Ian Jackson <ian.jackson@xxxxxxxxxx> 
> CC: Wei Liu <wei.liu2@xxxxxxxxxx> 
> CC: Chunyan Liu <cyliu@xxxxxxxx> 
> CC: Simon Cao <caobosimon@xxxxxxxxx> 
>  
>  
>  


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