[Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend

[Juergen Gross]

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.

The code is taken from the pvUSB implementation in Xen done by Fujitsu
based on Linux kernel 2.6.18.

Changes from the original version are:
- port to upstream kernel
- put all code in just one source file
- move module to appropriate location in kernel tree
- adapt to Linux style guide
- allocate resources dynamically
- use threaded irq
- correct sequence of state changes when assigning a device

Signed-off-by: Juergen Gross 
---
 drivers/usb/Makefile  |1 +
 drivers/usb/xen/Kconfig   |   10 +
 drivers/usb/xen/Makefile  |1 +
 drivers/usb/xen/xen-usbback.c | 1845 +
 4 files changed, 1857 insertions(+)
 create mode 100644 drivers/usb/xen/xen-usbback.c

diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 2676ef6..41f7398 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -64,3 +64,4 @@ obj-$(CONFIG_USB_COMMON)  += common/
 obj-$(CONFIG_USBIP_CORE)   += usbip/
 
 obj-$(CONFIG_XEN_USB_FRONTEND) += xen/
+obj-$(CONFIG_XEN_USB_BACKEND)  += xen/
diff --git a/drivers/usb/xen/Kconfig b/drivers/usb/xen/Kconfig
index 5d995477..3414617 100644
--- a/drivers/usb/xen/Kconfig
+++ b/drivers/usb/xen/Kconfig
@@ -8,3 +8,13 @@ config XEN_USB_FRONTEND
  within another guest OS (usually Dom0).
  Only needed if the kernel is running in a Xen guest and generic
  access to a USB device is needed.
+
+config XEN_USB_BACKEND
+   tristate "Xen USB backend driver"
+   depends on XEN_BACKEND
+   default m
+   help
+ The USB backend driver allows the kernel to export its USB Devices
+ to other guests via a high-performance shared-memory interface.
+ Only needed for systems running as Xen driver domains (e.g. Dom0) and
+ if guests need generic access to USB devices.
diff --git a/drivers/usb/xen/Makefile b/drivers/usb/xen/Makefile
index 4568c26..c1a571065 100644
--- a/drivers/usb/xen/Makefile
+++ b/drivers/usb/xen/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_XEN_USB_FRONTEND) += xen-usbfront.o
+obj-$(CONFIG_XEN_USB_BACKEND)  += xen-usbback.o
diff --git a/drivers/usb/xen/xen-usbback.c b/drivers/usb/xen/xen-usbback.c
new file mode 100644
index 000..56a600e
--- /dev/null
+++ b/drivers/usb/xen/xen-usbback.c
@@ -0,0 +1,1845 @@
+/*
+ * xen-usbback.c
+ *
+ * Xen USB backend driver.
+ *
+ * Copyright (C) 2009, FUJITSU LABORATORIES LTD.
+ * Author: Noboru Iwamatsu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ *
+ * or, by your choice,
+ *
+ * When distributed separately from the Linux kernel or incorporated into
+ * other software packages, subject to the following license:
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
+ * deal in the Software without restriction, including without limitation the
+ * rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+ * DEALINGS IN THE SOFTWARE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+struct usbstub;
+
+#define USBBACK_BUS_ID_SIZE 20
+#define USB_DEV_ADDR_SIZE 128
+
+struct usbback_info {
+   domid_t domid;
+   unsigned handle;
+   int num_ports;
+ 

Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend

[David Vrabel]

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

Re: [Xen-devel] [PATCH 3/4] usb: Introduce Xen pvUSB backend

[Juergen Gross]

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

[Ian Campbell]

On Wed, 2015-03-04 at 14:31 +0100, Juergen Gross wrote:
> >> - 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.

At least in the case of netback it really is just a normal Ethernet
driver as far as the kernel is concerned. The fact it happens to talk to
a virtual device doesn't matter.

I don't know about other device types.

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]

On 03/04/2015 02:41 PM, Ian Campbell wrote:

On Wed, 2015-03-04 at 14:31 +0100, Juergen Gross wrote:

- 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.


At least in the case of netback it really is just a normal Ethernet
driver as far as the kernel is concerned. The fact it happens to talk to
a virtual device doesn't matter.

I don't know about other device types.


usbback is just a normal USB driver as far as the kernel is concerned.
:-)


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

[David Vrabel]

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

[Juergen Gross]

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

[David Vrabel]

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

[Ian Campbell]

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

[Ian Campbell]

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

[Juergen Gross]

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.


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. :-)


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

[Peter Stuge]

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

[Greg KH]

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

[Juergen Gross]

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

[Pasi Kärkkäinen]

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

[Austin S Hemmelgarn]

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