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

Re: [Xen-devel] [RESEND][PATCH V16 0/6] xen pvusb toolstack work




>>> On 3/8/2016 at 07:33 PM, in message <56DEB899.7080007@xxxxxxxxxx>, George
Dunlap <george.dunlap@xxxxxxxxxx> wrote: 
> On 08/03/16 01:37, Chunyan Liu wrote: 
> > 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. 
> >  
> > RESEND to remove a incorrect rc in 4/6: 
> > +out: 
> > +    path = GCSPRINTF(USBBACK_INFO_PATH "/%s", usbdev_encode); 
> > +    rc = libxl__xs_rm_checked(gc, XBT_NULL, path); 
> > 'rc' should be removed here. 
> > +    return rc; 
> >  
> > Sorry for trouble you. 
>  
> Hey Chunyan, 
>  
> If you make any change at all to the patch series, you should increase 
> the revision number.  Otherwise, the person who ultimately commits it is 
> likely to think that the original version and the resend are the same, 
> and accidentally commit the original (incorrect) version.  (For 
> instance, they may already like me have downloaded the original patch 
> series and imported it into git.) 
>  
> The best thing to do in this situation would have been to reply to your 
> own patch, saying "And this 'rc' should be removed.  I'll spin another 
> version." 
>  
> I took a brief look at the diff between v14 and v15v1 yesterday, and it 
> looks good.  IanJ is away this week, and I'm sure he'll want to take a 
> look at it before Ack-ing it next week.  So would you mind sending a 
> v16, and I'll review it by the end of the week? 

Got it. Will post the RESEND series with a new version number.

>  
> Thanks, 
>  -George 
>  
> >  
> > Changes to V15: 
> > * address George's comments (patch 4/6) 
> >  
> > V15: 
> > http://lists.xen.org/archives/html/xen-devel/2016-03/msg00040.html 
> >  
> > V14: 
> > http://lists.xenproject.org/archives/html/xen-devel/2016-02/msg02745.html 
> >  
> > V13: 
> > http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg02125.html 
> >  
> > V12: 
> > http://lists.xen.org/archives/html/xen-devel/2015-12/msg02697.html 
> >  
> > V11: 
> > http://lists.xen.org/archives/html/xen-devel/2015-12/msg01626.html 
> >  
> > V10: 
> > http://lists.xen.org/archives/html/xen-devel/2015-12/msg01172.html 
> >  
> > V9: 
> > http://lists.xen.org/archives/html/xen-devel/2015-11/msg02744.html 
> >  
> > V8: 
> > http://lists.xen.org/archives/html/xen-devel/2015-10/msg02178.html 
> >  
> > V7: 
> > http://lists.xen.org/archives/html/xen-devel/2015-09/msg03115.html 
> >  
> > V6: 
> > http://lists.xen.org/archives/html/xen-devel/2015-08/msg00750.html 
> >  
> > V5: 
> > http://lists.xen.org/archives/html/xen-devel/2015-06/msg04052.html 
> >  
> > V4: 
> > http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01327.html 
> >  
> > Related Discussion Threads: 
> > http://www.redhat.com/archives/libvir-list/2014-June/msg00038.html 
> > http://lists.xen.org/archives/html/xen-devel/2014-06/msg00086.html 
> >  
> >               <<< 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=['hostbus=1, hostaddr=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=['hostbus=1, hostaddr=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 usbctrl-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 usbdev-attach domain hostbus=1 hostaddr=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 usbdev-detach command by giving 
> > controller:port 
> > e.g. 
> > xl usbdev-detach domain 0 1 
> >  
> > You can also remove the whole USB controller by usbctrl-detach 
> > command. 
> > e.g. 
> > xl usbctrl-detach domain 0 
> > It will remove the USB controller with index 0 and all USB devices 
> > under it. 
> >  
> > 4. PVUSB Libxl implementation 
> >  
> > * usbctrl-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. 
> >  
> > * usbctrl-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 
> >  
> > * usbdev-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. 
> >  
> > * usbdev-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. 
> >  
> > Chunyan Liu (6): 
> >   libxl: export some functions for pvusb use 
> >   libxl_utils: add internal function to read sysfs file contents 
> >   refactor DEFINE_DEVICE_REMOVE to fit for more device types 
> >   libxl: add pvusb API 
> >   domcreate: support pvusb in configuration file 
> >   xl: add pvusb commands 
> >  
> >  docs/man/xl.cfg.pod.5                |   84 ++ 
> >  docs/man/xl.pod.1                    |   37 + 
> >  tools/libxl/Makefile                 |    3 +- 
> >  tools/libxl/libxl.c                  |   41 +- 
> >  tools/libxl/libxl.h                  |   77 ++ 
> >  tools/libxl/libxl_create.c           |   73 +- 
> >  tools/libxl/libxl_device.c           |   17 +- 
> >  tools/libxl/libxl_internal.h         |   37 +- 
> >  tools/libxl/libxl_osdeps.h           |   13 + 
> >  tools/libxl/libxl_pvusb.c            | 1620  
> ++++++++++++++++++++++++++++++++++ 
> >  tools/libxl/libxl_types.idl          |   46 + 
> >  tools/libxl/libxl_types_internal.idl |    1 + 
> >  tools/libxl/libxl_utils.c            |   92 ++ 
> >  tools/libxl/libxl_utils.h            |    5 + 
> >  tools/libxl/xl.h                     |    5 + 
> >  tools/libxl/xl_cmdimpl.c             |  297 ++++++- 
> >  tools/libxl/xl_cmdtable.c            |   25 + 
> >  17 files changed, 2453 insertions(+), 20 deletions(-) 
> >  create mode 100644 tools/libxl/libxl_pvusb.c 
> >  
>  
>  
>  


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

 


Rackspace

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