Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On 2015-03-04 09:09, Juergen Gross wrote: The main question whether it is worth to consider this alternative is the performance aspect. Does anyone have an idea which USB devices would typically be used via pvusb? I'd suspect memory sticks and USB disks and perhaps webcams being the most performance relevant ones. Is an additional copy operation of user data acceptable here? Biggest use-cases I can think of for USB pass-through would be hardware 'security' devices (fingerprint readers, Yubikeys, SafeNet dongles), webcams, and some of the more exotic input devices. Webcams and input devices are probably the most significant performance-wise. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On Wed, Mar 04, 2015 at 02:46:33PM +, Ian Campbell wrote: On Wed, 2015-03-04 at 15:41 +0100, Juergen Gross wrote: On 03/04/2015 03:29 PM, Ian Campbell wrote: On Wed, 2015-03-04 at 14:19 +, David Vrabel wrote: On 04/03/15 14:09, Juergen Gross wrote: The main question whether it is worth to consider this alternative is the performance aspect. Does anyone have an idea which USB devices would typically be used via pvusb? I'd suspect memory sticks and USB disks and perhaps webcams being the most performance relevant ones. Is an additional copy operation of user data acceptable here? I have no idea. We (XenServer) have no use cases at all for USB device passthrough. I've seen XenServer customers asking for USB passthru functionality on IRC channels.. My gut feeling is that for USB 1 and 2 the bus itself isn't fast enough that anyone would care. qdisk has acceptable for disks, so it's probably ok for usb too. While I can accept the bus speed reasoning, I doubt qdisk is copying data between user and kernel space under normal circumstances. I think disk I/Os are done using DMA to/from the user buffer directly. I thought there was at least one copy on the datapath with qdisk, wherever it is. But I don't know for sure. For usb 3 onwards, well, maybe when we care about those we'll decide that a kernel space driver is needed, but for now it seems like userspace would be ok. Do you have another feeling about the probability of a need to do usb 3? If it is already on the horizon I wouldn't want to do the user space backend now and the kernel one next year. :-) Well, what is *your* use case for USB passthru? I don't actually have one myself. I'd speculate that people are more interested in passing in low/medium/high speed devices rather than the superfast usb3 disks etc. But I have no reason to back that up. People seem to ask/need USB passthru support for various use cases including passing thru: webcams, video grabbers, printers, mobile broadband modems, copy protection dongles, gaming controllers, you name it.. -- Pasi ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On Wed, Mar 04, 2015 at 02:31:08PM +0100, Juergen Gross wrote: On 03/02/2015 12:39 PM, David Vrabel wrote: On 26/02/15 13:35, Juergen Gross wrote: Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen domU to communicate with a USB device assigned to that domU. The communication is all done via the pvUSB backend in a driver domain (usually Dom0) which is owner of the physical device. Why do we need a kernel usb backend instead of a user-space one using libusb? Good question. At a first glance libusb seems to offer most/all needed interfaces. The main question is whether performance with libusb will be okay. There will be one additional copy of the I/O data needed if I've read the code in drivers/usb/core/devio.c correctly. You can drive USB devices at line speed using libusb just fine. Try it out and see please, processors copy data _very_ fast these days. thanks, greg k-h ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On 03/04/2015 04:27 PM, Greg KH wrote: On Wed, Mar 04, 2015 at 02:31:08PM +0100, Juergen Gross wrote: On 03/02/2015 12:39 PM, David Vrabel wrote: On 26/02/15 13:35, Juergen Gross wrote: Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen domU to communicate with a USB device assigned to that domU. The communication is all done via the pvUSB backend in a driver domain (usually Dom0) which is owner of the physical device. Why do we need a kernel usb backend instead of a user-space one using libusb? Good question. At a first glance libusb seems to offer most/all needed interfaces. The main question is whether performance with libusb will be okay. There will be one additional copy of the I/O data needed if I've read the code in drivers/usb/core/devio.c correctly. You can drive USB devices at line speed using libusb just fine. Try it out and see please, processors copy data _very_ fast these days. Okay, thanks for the information. I'll take this as a hint to try the user space variant. :-) Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On Wed, 2015-03-04 at 15:41 +0100, Juergen Gross wrote: On 03/04/2015 03:29 PM, Ian Campbell wrote: On Wed, 2015-03-04 at 14:19 +, David Vrabel wrote: On 04/03/15 14:09, Juergen Gross wrote: The main question whether it is worth to consider this alternative is the performance aspect. Does anyone have an idea which USB devices would typically be used via pvusb? I'd suspect memory sticks and USB disks and perhaps webcams being the most performance relevant ones. Is an additional copy operation of user data acceptable here? I have no idea. We (XenServer) have no use cases at all for USB device passthrough. My gut feeling is that for USB 1 and 2 the bus itself isn't fast enough that anyone would care. qdisk has acceptable for disks, so it's probably ok for usb too. While I can accept the bus speed reasoning, I doubt qdisk is copying data between user and kernel space under normal circumstances. I think disk I/Os are done using DMA to/from the user buffer directly. I thought there was at least one copy on the datapath with qdisk, wherever it is. But I don't know for sure. For usb 3 onwards, well, maybe when we care about those we'll decide that a kernel space driver is needed, but for now it seems like userspace would be ok. Do you have another feeling about the probability of a need to do usb 3? If it is already on the horizon I wouldn't want to do the user space backend now and the kernel one next year. :-) Well, what is *your* use case for USB passthru? I don't actually have one myself. I'd speculate that people are more interested in passing in low/medium/high speed devices rather than the superfast usb3 disks etc. But I have no reason to back that up. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On 03/02/2015 12:39 PM, David Vrabel wrote: On 26/02/15 13:35, Juergen Gross wrote: Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen domU to communicate with a USB device assigned to that domU. The communication is all done via the pvUSB backend in a driver domain (usually Dom0) which is owner of the physical device. Why do we need a kernel usb backend instead of a user-space one using libusb? Good question. At a first glance libusb seems to offer most/all needed interfaces. The main question is whether performance with libusb will be okay. There will be one additional copy of the I/O data needed if I've read the code in drivers/usb/core/devio.c correctly. I haven't worked with user space backends yet. Do you recommend a special example I should start with? Changes from the original version are: - port to upstream kernel - put all code in just one source file ?? I'm not sure that was an improvement. The resulting single file is too large IMO. OTOH this reduces overall code size: New file has 1845 lines, while old version had in sum 2243 lines with the largest file having 1217 lines. So the largest file is 50% larger, while overall size is 20% smaller. - move module to appropriate location in kernel tree drivers/xen/ is the correct location for this driver. Hmm, so you regard placement of xen-netback under drivers/net and xen-blkback under drivers/block as wrong? I've just followed these examples. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On 04/03/15 14:09, Juergen Gross wrote: The main question whether it is worth to consider this alternative is the performance aspect. Does anyone have an idea which USB devices would typically be used via pvusb? I'd suspect memory sticks and USB disks and perhaps webcams being the most performance relevant ones. Is an additional copy operation of user data acceptable here? I have no idea. We (XenServer) have no use cases at all for USB device passthrough. David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On 04/03/15 13:31, Juergen Gross wrote: On 03/02/2015 12:39 PM, David Vrabel wrote: On 26/02/15 13:35, Juergen Gross wrote: Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen domU to communicate with a USB device assigned to that domU. The communication is all done via the pvUSB backend in a driver domain (usually Dom0) which is owner of the physical device. Why do we need a kernel usb backend instead of a user-space one using libusb? Good question. At a first glance libusb seems to offer most/all needed interfaces. The main question is whether performance with libusb will be okay. There will be one additional copy of the I/O data needed if I've read the code in drivers/usb/core/devio.c correctly. I haven't worked with user space backends yet. Do you recommend a special example I should start with? Perhaps the block backend in qemu? Changes from the original version are: - port to upstream kernel - put all code in just one source file ?? I'm not sure that was an improvement. The resulting single file is too large IMO. OTOH this reduces overall code size: New file has 1845 lines, while old version had in sum 2243 lines with the largest file having 1217 lines. So the largest file is 50% larger, while overall size is 20% smaller. I think I would have preferred the original large file split up (if there's a sensible functional grouping of the resulting bits). If, after considering a userspace backend, you think that this kernel one is the way to go I'll give it another look and see if I can suggest a suitable split. - move module to appropriate location in kernel tree drivers/xen/ is the correct location for this driver. Hmm, so you regard placement of xen-netback under drivers/net and xen-blkback under drivers/block as wrong? I've just followed these examples. usbback is just a regular USB device driver and most of these don't live under drivers/usb/ but in the subsystem for the type of device they're providing (which in this case is a Xen backend, hence drivers/xen/). David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On 03/04/2015 02:53 PM, David Vrabel wrote: On 04/03/15 13:31, Juergen Gross wrote: On 03/02/2015 12:39 PM, David Vrabel wrote: On 26/02/15 13:35, Juergen Gross wrote: Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen domU to communicate with a USB device assigned to that domU. The communication is all done via the pvUSB backend in a driver domain (usually Dom0) which is owner of the physical device. Why do we need a kernel usb backend instead of a user-space one using libusb? Good question. At a first glance libusb seems to offer most/all needed interfaces. The main question is whether performance with libusb will be okay. There will be one additional copy of the I/O data needed if I've read the code in drivers/usb/core/devio.c correctly. I haven't worked with user space backends yet. Do you recommend a special example I should start with? Perhaps the block backend in qemu? Okay, so this would be driven by qemu then? The main question whether it is worth to consider this alternative is the performance aspect. Does anyone have an idea which USB devices would typically be used via pvusb? I'd suspect memory sticks and USB disks and perhaps webcams being the most performance relevant ones. Is an additional copy operation of user data acceptable here? Changes from the original version are: - port to upstream kernel - put all code in just one source file ?? I'm not sure that was an improvement. The resulting single file is too large IMO. OTOH this reduces overall code size: New file has 1845 lines, while old version had in sum 2243 lines with the largest file having 1217 lines. So the largest file is 50% larger, while overall size is 20% smaller. I think I would have preferred the original large file split up (if there's a sensible functional grouping of the resulting bits). If, after considering a userspace backend, you think that this kernel one is the way to go I'll give it another look and see if I can suggest a suitable split. I can split it up, if you really want. - move module to appropriate location in kernel tree drivers/xen/ is the correct location for this driver. Hmm, so you regard placement of xen-netback under drivers/net and xen-blkback under drivers/block as wrong? I've just followed these examples. usbback is just a regular USB device driver and most of these don't live under drivers/usb/ but in the subsystem for the type of device they're providing (which in this case is a Xen backend, hence drivers/xen/). Okay, I'll move it to drivers/xen. Juergen ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On Wed, 2015-03-04 at 14:19 +, David Vrabel wrote: On 04/03/15 14:09, Juergen Gross wrote: The main question whether it is worth to consider this alternative is the performance aspect. Does anyone have an idea which USB devices would typically be used via pvusb? I'd suspect memory sticks and USB disks and perhaps webcams being the most performance relevant ones. Is an additional copy operation of user data acceptable here? I have no idea. We (XenServer) have no use cases at all for USB device passthrough. My gut feeling is that for USB 1 and 2 the bus itself isn't fast enough that anyone would care. qdisk has acceptable for disks, so it's probably ok for usb too. For usb 3 onwards, well, maybe when we care about those we'll decide that a kernel space driver is needed, but for now it seems like userspace would be ok. Ian. ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
Juergen Gross wrote: Do you have another feeling about the probability of a need to do usb 3? If it is already on the horizon I wouldn't want to do the user space backend now and the kernel one next year. :-) One year is pretty long in kernel time. //Peter ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend
On 26/02/15 13:35, Juergen Gross wrote: Introduces the Xen pvUSB backend. With pvUSB it is possible for a Xen domU to communicate with a USB device assigned to that domU. The communication is all done via the pvUSB backend in a driver domain (usually Dom0) which is owner of the physical device. Why do we need a kernel usb backend instead of a user-space one using libusb? Changes from the original version are: - port to upstream kernel - put all code in just one source file ?? I'm not sure that was an improvement. The resulting single file is too large IMO. - move module to appropriate location in kernel tree drivers/xen/ is the correct location for this driver. (I've not given the driver a detailed review yet.) David ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
