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

[Juergen Gross <jgross@suse.com>]

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