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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54F71221.6050800@suse.com>
Date:	Wed, 04 Mar 2015 15:09:37 +0100
From:	Juergen Gross <jgross@...e.com>
To:	David Vrabel <david.vrabel@...rix.com>,
	linux-kernel@...r.kernel.org, xen-devel@...ts.xensource.com,
	konrad.wilk@...cle.com, boris.ostrovsky@...cle.com,
	linux-usb@...r.kernel.org, gregkh@...uxfoundation.org,
	cyliu@...e.com
Subject: 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/