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

From: Juergen Gross
Date: Wed Mar 04 2015 - 09:09:44 EST


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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/