2017-11-03 18:28:30 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0+
|
2008-07-10 04:56:51 +08:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2003-2008 Takahiro Hirofuchi
|
|
|
|
*/
|
|
|
|
|
2011-05-12 13:33:43 +08:00
|
|
|
#include <linux/string.h>
|
2011-07-04 03:49:50 +08:00
|
|
|
#include <linux/module.h>
|
2014-03-08 20:53:33 +08:00
|
|
|
#include <linux/device.h>
|
usbip: Implement SG support to vhci-hcd and stub driver
There are bugs on vhci with usb 3.0 storage device. In USB, each SG
list entry buffer should be divisible by the bulk max packet size.
But with native SG support, this problem doesn't matter because the
SG buffer is treated as contiguous buffer. But without native SG
support, USB storage driver breaks SG list into several URBs and the
error occurs because of a buffer size of URB that cannot be divided
by the bulk max packet size. The error situation is as follows.
When USB Storage driver requests 31.5 KB data and has SG list which
has 3584 bytes buffer followed by 7 4096 bytes buffer for some
reason. USB Storage driver splits this SG list into several URBs
because VHCI doesn't support SG and sends them separately. So the
first URB buffer size is 3584 bytes. When receiving data from device,
USB 3.0 device sends data packet of 1024 bytes size because the max
packet size of BULK pipe is 1024 bytes. So device sends 4096 bytes.
But the first URB buffer has only 3584 bytes buffer size. So host
controller terminates the transfer even though there is more data to
receive. So, vhci needs to support SG transfer to prevent this error.
In this patch, vhci supports SG regardless of whether the server's
host controller supports SG or not, because stub driver splits SG
list into several URBs if the server's host controller doesn't
support SG.
To support SG, vhci sets URB_DMA_MAP_SG flag in urb->transfer_flags
if URB has SG list and this flag will tell stub driver to use SG
list. After receiving urb from stub driver, vhci clear URB_DMA_MAP_SG
flag to avoid unnecessary DMA unmapping in HCD.
vhci sends each SG list entry to stub driver. Then, stub driver sees
the total length of the buffer and allocates SG table and pages
according to the total buffer length calling sgl_alloc(). After stub
driver receives completed URB, it again sends each SG list entry to
vhci.
If the server's host controller doesn't support SG, stub driver
breaks a single SG request into several URBs and submits them to
the server's host controller. When all the split URBs are completed,
stub driver reassembles the URBs into a single return command and
sends it to vhci.
Moreover, in the situation where vhci supports SG, but stub driver
does not, or vice versa, usbip works normally. Because there is no
protocol modification, there is no problem in communication between
server and client even if the one has a kernel without SG support.
In the case of vhci supports SG and stub driver doesn't, because
vhci sends only the total length of the buffer to stub driver as
it did before the patch applied, stub driver only needs to allocate
the required length of buffers using only kmalloc() regardless of
whether vhci supports SG or not. But stub driver has to allocate
buffer with kmalloc() as much as the total length of SG buffer which
is quite huge when vhci sends SG request, so it has overhead in
buffer allocation in this situation.
If stub driver needs to send data buffer to vhci because of IN pipe,
stub driver also sends only total length of buffer as metadata and
then sends real data as vhci does. Then vhci receive data from stub
driver and store it to the corresponding buffer of SG list entry.
And for the case of stub driver supports SG and vhci doesn't, since
the USB storage driver checks that vhci doesn't support SG and sends
the request to stub driver by splitting the SG list into multiple
URBs, stub driver allocates a buffer for each URB with kmalloc() as
it did before this patch.
* Test environment
Test uses two difference machines and two different kernel version
to make mismatch situation between the client and the server where
vhci supports SG, but stub driver does not, or vice versa. All tests
are conducted in both full SG support that both vhci and stub support
SG and half SG support that is the mismatch situation. Test kernel
version is 5.3-rc6 with commit "usb: add a HCD_DMA flag instead of
guestimating DMA capabilities" to avoid unnecessary DMA mapping and
unmapping.
- Test kernel version
- 5.3-rc6 with SG support
- 5.1.20-200.fc29.x86_64 without SG support
* SG support test
- Test devices
- Super-speed storage device - SanDisk Ultra USB 3.0
- High-speed storage device - SMI corporation USB 2.0 flash drive
- Test description
Test read and write operation of mass storage device that uses the
BULK transfer. In test, the client reads and writes files whose size
is over 1G and it works normally.
* Regression test
- Test devices
- Super-speed device - Logitech Brio webcam
- High-speed device - Logitech C920 HD Pro webcam
- Full-speed device - Logitech bluetooth mouse
- Britz BR-Orion speaker
- Low-speed device - Logitech wired mouse
- Test description
Moving and click test for mouse. To test the webcam, use gnome-cheese.
To test the speaker, play music and video on the client. All works
normally.
* VUDC compatibility test
VUDC also works well with this patch. Tests are done with two USB
gadget created by CONFIGFS USB gadget. Both use the BULK pipe.
1. Serial gadget
2. Mass storage gadget
- Serial gadget test
Serial gadget on the host sends and receives data using cat command
on the /dev/ttyGS<N>. The client uses minicom to communicate with
the serial gadget.
- Mass storage gadget test
After connecting the gadget with vhci, use "dd" to test read and
write operation on the client side.
Read - dd if=/dev/sd<N> iflag=direct of=/dev/null bs=1G count=1
Write - dd if=<my file path> iflag=direct of=/dev/sd<N> bs=1G count=1
Signed-off-by: Suwan Kim <suwan.kim027@gmail.com>
Acked-by: Shuah khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20190828032741.12234-1-suwan.kim027@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-28 11:27:41 +08:00
|
|
|
#include <linux/scatterlist.h>
|
2008-07-10 04:56:51 +08:00
|
|
|
|
|
|
|
#include "usbip_common.h"
|
|
|
|
#include "stub.h"
|
|
|
|
|
|
|
|
#define DRIVER_AUTHOR "Takahiro Hirofuchi"
|
2011-05-12 13:33:44 +08:00
|
|
|
#define DRIVER_DESC "USB/IP Host Driver"
|
2008-07-10 04:56:51 +08:00
|
|
|
|
|
|
|
struct kmem_cache *stub_priv_cache;
|
2018-05-01 06:17:20 +08:00
|
|
|
|
2008-07-10 04:56:51 +08:00
|
|
|
/*
|
|
|
|
* busid_tables defines matching busids that usbip can grab. A user can change
|
|
|
|
* dynamically what device is locally used and what device is exported to a
|
|
|
|
* remote host.
|
|
|
|
*/
|
|
|
|
#define MAX_BUSID 16
|
2010-07-27 18:39:30 +08:00
|
|
|
static struct bus_id_priv busid_table[MAX_BUSID];
|
2008-07-10 04:56:51 +08:00
|
|
|
static spinlock_t busid_table_lock;
|
|
|
|
|
2011-05-20 12:36:57 +08:00
|
|
|
static void init_busid_table(void)
|
|
|
|
{
|
2018-05-15 10:49:58 +08:00
|
|
|
int i;
|
|
|
|
|
2013-04-04 22:03:10 +08:00
|
|
|
/*
|
|
|
|
* This also sets the bus_table[i].status to
|
|
|
|
* STUB_BUSID_OTHER, which is 0.
|
|
|
|
*/
|
2011-05-27 16:49:24 +08:00
|
|
|
memset(busid_table, 0, sizeof(busid_table));
|
2011-05-20 12:36:57 +08:00
|
|
|
|
|
|
|
spin_lock_init(&busid_table_lock);
|
2018-05-15 10:49:58 +08:00
|
|
|
|
|
|
|
for (i = 0; i < MAX_BUSID; i++)
|
|
|
|
spin_lock_init(&busid_table[i].busid_lock);
|
2011-05-20 12:36:57 +08:00
|
|
|
}
|
|
|
|
|
2011-05-20 12:36:58 +08:00
|
|
|
/*
|
|
|
|
* Find the index of the busid by name.
|
|
|
|
* Must be called with busid_table_lock held.
|
|
|
|
*/
|
|
|
|
static int get_busid_idx(const char *busid)
|
2008-07-10 04:56:51 +08:00
|
|
|
{
|
|
|
|
int i;
|
2011-05-20 12:36:58 +08:00
|
|
|
int idx = -1;
|
2008-07-10 04:56:51 +08:00
|
|
|
|
2018-05-15 10:49:58 +08:00
|
|
|
for (i = 0; i < MAX_BUSID; i++) {
|
|
|
|
spin_lock(&busid_table[i].busid_lock);
|
2010-07-27 18:39:30 +08:00
|
|
|
if (busid_table[i].name[0])
|
|
|
|
if (!strncmp(busid_table[i].name, busid, BUSID_SIZE)) {
|
2011-05-20 12:36:58 +08:00
|
|
|
idx = i;
|
2018-05-15 10:49:58 +08:00
|
|
|
spin_unlock(&busid_table[i].busid_lock);
|
2011-05-20 12:36:58 +08:00
|
|
|
break;
|
2008-07-10 04:56:51 +08:00
|
|
|
}
|
2018-05-15 10:49:58 +08:00
|
|
|
spin_unlock(&busid_table[i].busid_lock);
|
|
|
|
}
|
2011-05-20 12:36:58 +08:00
|
|
|
return idx;
|
2008-07-10 04:56:51 +08:00
|
|
|
}
|
|
|
|
|
2018-05-15 10:49:58 +08:00
|
|
|
/* Returns holding busid_lock. Should call put_busid_priv() to unlock */
|
2010-07-27 18:39:30 +08:00
|
|
|
struct bus_id_priv *get_busid_priv(const char *busid)
|
|
|
|
{
|
2011-05-20 12:36:58 +08:00
|
|
|
int idx;
|
|
|
|
struct bus_id_priv *bid = NULL;
|
2010-07-27 18:39:30 +08:00
|
|
|
|
|
|
|
spin_lock(&busid_table_lock);
|
2011-05-20 12:36:58 +08:00
|
|
|
idx = get_busid_idx(busid);
|
2018-05-15 10:49:58 +08:00
|
|
|
if (idx >= 0) {
|
2011-05-20 12:36:58 +08:00
|
|
|
bid = &(busid_table[idx]);
|
2018-05-15 10:49:58 +08:00
|
|
|
/* get busid_lock before returning */
|
|
|
|
spin_lock(&bid->busid_lock);
|
|
|
|
}
|
2010-07-27 18:39:30 +08:00
|
|
|
spin_unlock(&busid_table_lock);
|
|
|
|
|
2011-05-20 12:36:58 +08:00
|
|
|
return bid;
|
2010-07-27 18:39:30 +08:00
|
|
|
}
|
|
|
|
|
2018-05-15 10:49:58 +08:00
|
|
|
void put_busid_priv(struct bus_id_priv *bid)
|
|
|
|
{
|
2018-05-16 07:57:23 +08:00
|
|
|
if (bid)
|
|
|
|
spin_unlock(&bid->busid_lock);
|
2018-05-15 10:49:58 +08:00
|
|
|
}
|
|
|
|
|
2008-07-10 04:56:51 +08:00
|
|
|
static int add_match_busid(char *busid)
|
|
|
|
{
|
|
|
|
int i;
|
2011-05-20 12:36:58 +08:00
|
|
|
int ret = -1;
|
2008-07-10 04:56:51 +08:00
|
|
|
|
|
|
|
spin_lock(&busid_table_lock);
|
2011-05-20 12:36:58 +08:00
|
|
|
/* already registered? */
|
|
|
|
if (get_busid_idx(busid) >= 0) {
|
|
|
|
ret = 0;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2018-05-15 10:49:58 +08:00
|
|
|
for (i = 0; i < MAX_BUSID; i++) {
|
|
|
|
spin_lock(&busid_table[i].busid_lock);
|
2010-07-27 18:39:30 +08:00
|
|
|
if (!busid_table[i].name[0]) {
|
2014-07-26 22:43:20 +08:00
|
|
|
strlcpy(busid_table[i].name, busid, BUSID_SIZE);
|
2010-07-27 18:39:30 +08:00
|
|
|
if ((busid_table[i].status != STUB_BUSID_ALLOC) &&
|
|
|
|
(busid_table[i].status != STUB_BUSID_REMOV))
|
|
|
|
busid_table[i].status = STUB_BUSID_ADDED;
|
2011-05-20 12:36:58 +08:00
|
|
|
ret = 0;
|
2018-05-15 10:49:58 +08:00
|
|
|
spin_unlock(&busid_table[i].busid_lock);
|
2011-05-20 12:36:58 +08:00
|
|
|
break;
|
2008-07-10 04:56:51 +08:00
|
|
|
}
|
2018-05-15 10:49:58 +08:00
|
|
|
spin_unlock(&busid_table[i].busid_lock);
|
|
|
|
}
|
2011-05-20 12:36:58 +08:00
|
|
|
|
|
|
|
out:
|
2008-07-10 04:56:51 +08:00
|
|
|
spin_unlock(&busid_table_lock);
|
|
|
|
|
2011-05-20 12:36:58 +08:00
|
|
|
return ret;
|
2008-07-10 04:56:51 +08:00
|
|
|
}
|
|
|
|
|
2010-07-27 18:39:30 +08:00
|
|
|
int del_match_busid(char *busid)
|
2008-07-10 04:56:51 +08:00
|
|
|
{
|
2011-05-20 12:36:58 +08:00
|
|
|
int idx;
|
|
|
|
int ret = -1;
|
2008-07-10 04:56:51 +08:00
|
|
|
|
|
|
|
spin_lock(&busid_table_lock);
|
2011-05-20 12:36:58 +08:00
|
|
|
idx = get_busid_idx(busid);
|
|
|
|
if (idx < 0)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
/* found */
|
|
|
|
ret = 0;
|
|
|
|
|
2018-05-15 10:49:58 +08:00
|
|
|
spin_lock(&busid_table[idx].busid_lock);
|
|
|
|
|
2011-05-20 12:36:58 +08:00
|
|
|
if (busid_table[idx].status == STUB_BUSID_OTHER)
|
|
|
|
memset(busid_table[idx].name, 0, BUSID_SIZE);
|
|
|
|
|
|
|
|
if ((busid_table[idx].status != STUB_BUSID_OTHER) &&
|
|
|
|
(busid_table[idx].status != STUB_BUSID_ADDED))
|
|
|
|
busid_table[idx].status = STUB_BUSID_REMOV;
|
|
|
|
|
2018-05-15 10:49:58 +08:00
|
|
|
spin_unlock(&busid_table[idx].busid_lock);
|
2011-05-20 12:36:58 +08:00
|
|
|
out:
|
2008-07-10 04:56:51 +08:00
|
|
|
spin_unlock(&busid_table_lock);
|
|
|
|
|
2011-05-20 12:36:58 +08:00
|
|
|
return ret;
|
2008-07-10 04:56:51 +08:00
|
|
|
}
|
2011-05-06 18:47:42 +08:00
|
|
|
|
2017-06-09 17:03:14 +08:00
|
|
|
static ssize_t match_busid_show(struct device_driver *drv, char *buf)
|
2010-07-27 18:39:30 +08:00
|
|
|
{
|
|
|
|
int i;
|
2011-05-20 12:36:57 +08:00
|
|
|
char *out = buf;
|
2010-07-27 18:39:30 +08:00
|
|
|
|
2011-05-20 12:36:57 +08:00
|
|
|
spin_lock(&busid_table_lock);
|
2018-05-15 10:49:58 +08:00
|
|
|
for (i = 0; i < MAX_BUSID; i++) {
|
|
|
|
spin_lock(&busid_table[i].busid_lock);
|
2011-05-20 12:36:57 +08:00
|
|
|
if (busid_table[i].name[0])
|
|
|
|
out += sprintf(out, "%s ", busid_table[i].name);
|
2018-05-15 10:49:58 +08:00
|
|
|
spin_unlock(&busid_table[i].busid_lock);
|
|
|
|
}
|
2011-05-20 12:36:57 +08:00
|
|
|
spin_unlock(&busid_table_lock);
|
|
|
|
out += sprintf(out, "\n");
|
2011-05-20 12:36:58 +08:00
|
|
|
|
2011-05-20 12:36:57 +08:00
|
|
|
return out - buf;
|
2010-07-27 18:39:30 +08:00
|
|
|
}
|
2008-07-10 04:56:51 +08:00
|
|
|
|
2017-06-09 17:03:14 +08:00
|
|
|
static ssize_t match_busid_store(struct device_driver *dev, const char *buf,
|
2011-05-06 18:47:42 +08:00
|
|
|
size_t count)
|
2008-07-10 04:56:51 +08:00
|
|
|
{
|
|
|
|
int len;
|
2008-10-30 08:59:32 +08:00
|
|
|
char busid[BUSID_SIZE];
|
2008-07-10 04:56:51 +08:00
|
|
|
|
|
|
|
if (count < 5)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* busid needs to include \0 termination */
|
2014-07-26 22:43:20 +08:00
|
|
|
len = strlcpy(busid, buf + 4, BUSID_SIZE);
|
|
|
|
if (sizeof(busid) <= len)
|
2008-07-10 04:56:51 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!strncmp(buf, "add ", 4)) {
|
2013-04-04 22:03:09 +08:00
|
|
|
if (add_match_busid(busid) < 0)
|
2008-07-10 04:56:51 +08:00
|
|
|
return -ENOMEM;
|
2013-04-04 22:03:09 +08:00
|
|
|
|
|
|
|
pr_debug("add busid %s\n", busid);
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!strncmp(buf, "del ", 4)) {
|
|
|
|
if (del_match_busid(busid) < 0)
|
2008-07-10 04:56:51 +08:00
|
|
|
return -ENODEV;
|
2013-04-04 22:03:09 +08:00
|
|
|
|
|
|
|
pr_debug("del busid %s\n", busid);
|
|
|
|
return count;
|
2011-05-20 12:36:58 +08:00
|
|
|
}
|
2013-04-04 22:03:09 +08:00
|
|
|
|
|
|
|
return -EINVAL;
|
2008-07-10 04:56:51 +08:00
|
|
|
}
|
2017-06-09 17:03:14 +08:00
|
|
|
static DRIVER_ATTR_RW(match_busid);
|
2008-07-10 04:56:51 +08:00
|
|
|
|
2018-05-01 06:17:20 +08:00
|
|
|
static int do_rebind(char *busid, struct bus_id_priv *busid_priv)
|
|
|
|
{
|
2019-05-03 03:47:18 +08:00
|
|
|
int ret = 0;
|
2018-05-01 06:17:20 +08:00
|
|
|
|
|
|
|
/* device_attach() callers should hold parent lock for USB */
|
|
|
|
if (busid_priv->udev->dev.parent)
|
|
|
|
device_lock(busid_priv->udev->dev.parent);
|
|
|
|
ret = device_attach(&busid_priv->udev->dev);
|
|
|
|
if (busid_priv->udev->dev.parent)
|
|
|
|
device_unlock(busid_priv->udev->dev.parent);
|
2019-05-03 03:47:18 +08:00
|
|
|
if (ret < 0)
|
2018-05-01 06:17:20 +08:00
|
|
|
dev_err(&busid_priv->udev->dev, "rebind failed\n");
|
2019-05-03 03:47:18 +08:00
|
|
|
return ret;
|
2018-05-01 06:17:20 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void stub_device_rebind(void)
|
|
|
|
{
|
|
|
|
#if IS_MODULE(CONFIG_USBIP_HOST)
|
|
|
|
struct bus_id_priv *busid_priv;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
/* update status to STUB_BUSID_OTHER so probe ignores the device */
|
|
|
|
spin_lock(&busid_table_lock);
|
|
|
|
for (i = 0; i < MAX_BUSID; i++) {
|
|
|
|
if (busid_table[i].name[0] &&
|
|
|
|
busid_table[i].shutdown_busid) {
|
|
|
|
busid_priv = &(busid_table[i]);
|
|
|
|
busid_priv->status = STUB_BUSID_OTHER;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
spin_unlock(&busid_table_lock);
|
|
|
|
|
2018-05-15 10:49:58 +08:00
|
|
|
/* now run rebind - no need to hold locks. driver files are removed */
|
2018-05-01 06:17:20 +08:00
|
|
|
for (i = 0; i < MAX_BUSID; i++) {
|
|
|
|
if (busid_table[i].name[0] &&
|
|
|
|
busid_table[i].shutdown_busid) {
|
|
|
|
busid_priv = &(busid_table[i]);
|
|
|
|
do_rebind(busid_table[i].name, busid_priv);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2014-03-08 20:53:33 +08:00
|
|
|
static ssize_t rebind_store(struct device_driver *dev, const char *buf,
|
|
|
|
size_t count)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
int len;
|
|
|
|
struct bus_id_priv *bid;
|
|
|
|
|
|
|
|
/* buf length should be less that BUSID_SIZE */
|
|
|
|
len = strnlen(buf, BUSID_SIZE);
|
|
|
|
|
|
|
|
if (!(len < BUSID_SIZE))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
bid = get_busid_priv(buf);
|
|
|
|
if (!bid)
|
|
|
|
return -ENODEV;
|
|
|
|
|
2018-05-01 06:17:19 +08:00
|
|
|
/* mark the device for deletion so probe ignores it during rescan */
|
|
|
|
bid->status = STUB_BUSID_OTHER;
|
2018-05-15 10:49:58 +08:00
|
|
|
/* release the busid lock */
|
|
|
|
put_busid_priv(bid);
|
2018-05-01 06:17:19 +08:00
|
|
|
|
2018-05-01 06:17:20 +08:00
|
|
|
ret = do_rebind((char *) buf, bid);
|
|
|
|
if (ret < 0)
|
2014-03-08 20:53:33 +08:00
|
|
|
return ret;
|
|
|
|
|
2018-05-01 06:17:19 +08:00
|
|
|
/* delete device from busid_table */
|
|
|
|
del_match_busid((char *) buf);
|
|
|
|
|
2014-03-08 20:53:33 +08:00
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static DRIVER_ATTR_WO(rebind);
|
|
|
|
|
2008-07-10 04:56:51 +08:00
|
|
|
static struct stub_priv *stub_priv_pop_from_listhead(struct list_head *listhead)
|
|
|
|
{
|
|
|
|
struct stub_priv *priv, *tmp;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(priv, tmp, listhead, list) {
|
usbip: Implement SG support to vhci-hcd and stub driver
There are bugs on vhci with usb 3.0 storage device. In USB, each SG
list entry buffer should be divisible by the bulk max packet size.
But with native SG support, this problem doesn't matter because the
SG buffer is treated as contiguous buffer. But without native SG
support, USB storage driver breaks SG list into several URBs and the
error occurs because of a buffer size of URB that cannot be divided
by the bulk max packet size. The error situation is as follows.
When USB Storage driver requests 31.5 KB data and has SG list which
has 3584 bytes buffer followed by 7 4096 bytes buffer for some
reason. USB Storage driver splits this SG list into several URBs
because VHCI doesn't support SG and sends them separately. So the
first URB buffer size is 3584 bytes. When receiving data from device,
USB 3.0 device sends data packet of 1024 bytes size because the max
packet size of BULK pipe is 1024 bytes. So device sends 4096 bytes.
But the first URB buffer has only 3584 bytes buffer size. So host
controller terminates the transfer even though there is more data to
receive. So, vhci needs to support SG transfer to prevent this error.
In this patch, vhci supports SG regardless of whether the server's
host controller supports SG or not, because stub driver splits SG
list into several URBs if the server's host controller doesn't
support SG.
To support SG, vhci sets URB_DMA_MAP_SG flag in urb->transfer_flags
if URB has SG list and this flag will tell stub driver to use SG
list. After receiving urb from stub driver, vhci clear URB_DMA_MAP_SG
flag to avoid unnecessary DMA unmapping in HCD.
vhci sends each SG list entry to stub driver. Then, stub driver sees
the total length of the buffer and allocates SG table and pages
according to the total buffer length calling sgl_alloc(). After stub
driver receives completed URB, it again sends each SG list entry to
vhci.
If the server's host controller doesn't support SG, stub driver
breaks a single SG request into several URBs and submits them to
the server's host controller. When all the split URBs are completed,
stub driver reassembles the URBs into a single return command and
sends it to vhci.
Moreover, in the situation where vhci supports SG, but stub driver
does not, or vice versa, usbip works normally. Because there is no
protocol modification, there is no problem in communication between
server and client even if the one has a kernel without SG support.
In the case of vhci supports SG and stub driver doesn't, because
vhci sends only the total length of the buffer to stub driver as
it did before the patch applied, stub driver only needs to allocate
the required length of buffers using only kmalloc() regardless of
whether vhci supports SG or not. But stub driver has to allocate
buffer with kmalloc() as much as the total length of SG buffer which
is quite huge when vhci sends SG request, so it has overhead in
buffer allocation in this situation.
If stub driver needs to send data buffer to vhci because of IN pipe,
stub driver also sends only total length of buffer as metadata and
then sends real data as vhci does. Then vhci receive data from stub
driver and store it to the corresponding buffer of SG list entry.
And for the case of stub driver supports SG and vhci doesn't, since
the USB storage driver checks that vhci doesn't support SG and sends
the request to stub driver by splitting the SG list into multiple
URBs, stub driver allocates a buffer for each URB with kmalloc() as
it did before this patch.
* Test environment
Test uses two difference machines and two different kernel version
to make mismatch situation between the client and the server where
vhci supports SG, but stub driver does not, or vice versa. All tests
are conducted in both full SG support that both vhci and stub support
SG and half SG support that is the mismatch situation. Test kernel
version is 5.3-rc6 with commit "usb: add a HCD_DMA flag instead of
guestimating DMA capabilities" to avoid unnecessary DMA mapping and
unmapping.
- Test kernel version
- 5.3-rc6 with SG support
- 5.1.20-200.fc29.x86_64 without SG support
* SG support test
- Test devices
- Super-speed storage device - SanDisk Ultra USB 3.0
- High-speed storage device - SMI corporation USB 2.0 flash drive
- Test description
Test read and write operation of mass storage device that uses the
BULK transfer. In test, the client reads and writes files whose size
is over 1G and it works normally.
* Regression test
- Test devices
- Super-speed device - Logitech Brio webcam
- High-speed device - Logitech C920 HD Pro webcam
- Full-speed device - Logitech bluetooth mouse
- Britz BR-Orion speaker
- Low-speed device - Logitech wired mouse
- Test description
Moving and click test for mouse. To test the webcam, use gnome-cheese.
To test the speaker, play music and video on the client. All works
normally.
* VUDC compatibility test
VUDC also works well with this patch. Tests are done with two USB
gadget created by CONFIGFS USB gadget. Both use the BULK pipe.
1. Serial gadget
2. Mass storage gadget
- Serial gadget test
Serial gadget on the host sends and receives data using cat command
on the /dev/ttyGS<N>. The client uses minicom to communicate with
the serial gadget.
- Mass storage gadget test
After connecting the gadget with vhci, use "dd" to test read and
write operation on the client side.
Read - dd if=/dev/sd<N> iflag=direct of=/dev/null bs=1G count=1
Write - dd if=<my file path> iflag=direct of=/dev/sd<N> bs=1G count=1
Signed-off-by: Suwan Kim <suwan.kim027@gmail.com>
Acked-by: Shuah khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20190828032741.12234-1-suwan.kim027@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-28 11:27:41 +08:00
|
|
|
list_del_init(&priv->list);
|
2008-07-10 04:56:51 +08:00
|
|
|
return priv;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
usbip: Implement SG support to vhci-hcd and stub driver
There are bugs on vhci with usb 3.0 storage device. In USB, each SG
list entry buffer should be divisible by the bulk max packet size.
But with native SG support, this problem doesn't matter because the
SG buffer is treated as contiguous buffer. But without native SG
support, USB storage driver breaks SG list into several URBs and the
error occurs because of a buffer size of URB that cannot be divided
by the bulk max packet size. The error situation is as follows.
When USB Storage driver requests 31.5 KB data and has SG list which
has 3584 bytes buffer followed by 7 4096 bytes buffer for some
reason. USB Storage driver splits this SG list into several URBs
because VHCI doesn't support SG and sends them separately. So the
first URB buffer size is 3584 bytes. When receiving data from device,
USB 3.0 device sends data packet of 1024 bytes size because the max
packet size of BULK pipe is 1024 bytes. So device sends 4096 bytes.
But the first URB buffer has only 3584 bytes buffer size. So host
controller terminates the transfer even though there is more data to
receive. So, vhci needs to support SG transfer to prevent this error.
In this patch, vhci supports SG regardless of whether the server's
host controller supports SG or not, because stub driver splits SG
list into several URBs if the server's host controller doesn't
support SG.
To support SG, vhci sets URB_DMA_MAP_SG flag in urb->transfer_flags
if URB has SG list and this flag will tell stub driver to use SG
list. After receiving urb from stub driver, vhci clear URB_DMA_MAP_SG
flag to avoid unnecessary DMA unmapping in HCD.
vhci sends each SG list entry to stub driver. Then, stub driver sees
the total length of the buffer and allocates SG table and pages
according to the total buffer length calling sgl_alloc(). After stub
driver receives completed URB, it again sends each SG list entry to
vhci.
If the server's host controller doesn't support SG, stub driver
breaks a single SG request into several URBs and submits them to
the server's host controller. When all the split URBs are completed,
stub driver reassembles the URBs into a single return command and
sends it to vhci.
Moreover, in the situation where vhci supports SG, but stub driver
does not, or vice versa, usbip works normally. Because there is no
protocol modification, there is no problem in communication between
server and client even if the one has a kernel without SG support.
In the case of vhci supports SG and stub driver doesn't, because
vhci sends only the total length of the buffer to stub driver as
it did before the patch applied, stub driver only needs to allocate
the required length of buffers using only kmalloc() regardless of
whether vhci supports SG or not. But stub driver has to allocate
buffer with kmalloc() as much as the total length of SG buffer which
is quite huge when vhci sends SG request, so it has overhead in
buffer allocation in this situation.
If stub driver needs to send data buffer to vhci because of IN pipe,
stub driver also sends only total length of buffer as metadata and
then sends real data as vhci does. Then vhci receive data from stub
driver and store it to the corresponding buffer of SG list entry.
And for the case of stub driver supports SG and vhci doesn't, since
the USB storage driver checks that vhci doesn't support SG and sends
the request to stub driver by splitting the SG list into multiple
URBs, stub driver allocates a buffer for each URB with kmalloc() as
it did before this patch.
* Test environment
Test uses two difference machines and two different kernel version
to make mismatch situation between the client and the server where
vhci supports SG, but stub driver does not, or vice versa. All tests
are conducted in both full SG support that both vhci and stub support
SG and half SG support that is the mismatch situation. Test kernel
version is 5.3-rc6 with commit "usb: add a HCD_DMA flag instead of
guestimating DMA capabilities" to avoid unnecessary DMA mapping and
unmapping.
- Test kernel version
- 5.3-rc6 with SG support
- 5.1.20-200.fc29.x86_64 without SG support
* SG support test
- Test devices
- Super-speed storage device - SanDisk Ultra USB 3.0
- High-speed storage device - SMI corporation USB 2.0 flash drive
- Test description
Test read and write operation of mass storage device that uses the
BULK transfer. In test, the client reads and writes files whose size
is over 1G and it works normally.
* Regression test
- Test devices
- Super-speed device - Logitech Brio webcam
- High-speed device - Logitech C920 HD Pro webcam
- Full-speed device - Logitech bluetooth mouse
- Britz BR-Orion speaker
- Low-speed device - Logitech wired mouse
- Test description
Moving and click test for mouse. To test the webcam, use gnome-cheese.
To test the speaker, play music and video on the client. All works
normally.
* VUDC compatibility test
VUDC also works well with this patch. Tests are done with two USB
gadget created by CONFIGFS USB gadget. Both use the BULK pipe.
1. Serial gadget
2. Mass storage gadget
- Serial gadget test
Serial gadget on the host sends and receives data using cat command
on the /dev/ttyGS<N>. The client uses minicom to communicate with
the serial gadget.
- Mass storage gadget test
After connecting the gadget with vhci, use "dd" to test read and
write operation on the client side.
Read - dd if=/dev/sd<N> iflag=direct of=/dev/null bs=1G count=1
Write - dd if=<my file path> iflag=direct of=/dev/sd<N> bs=1G count=1
Signed-off-by: Suwan Kim <suwan.kim027@gmail.com>
Acked-by: Shuah khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20190828032741.12234-1-suwan.kim027@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-28 11:27:41 +08:00
|
|
|
void stub_free_priv_and_urb(struct stub_priv *priv)
|
|
|
|
{
|
|
|
|
struct urb *urb;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < priv->num_urbs; i++) {
|
|
|
|
urb = priv->urbs[i];
|
|
|
|
|
|
|
|
if (!urb)
|
|
|
|
return;
|
|
|
|
|
|
|
|
kfree(urb->setup_packet);
|
|
|
|
urb->setup_packet = NULL;
|
|
|
|
|
|
|
|
|
|
|
|
if (urb->transfer_buffer && !priv->sgl) {
|
|
|
|
kfree(urb->transfer_buffer);
|
|
|
|
urb->transfer_buffer = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (urb->num_sgs) {
|
|
|
|
sgl_free(urb->sg);
|
|
|
|
urb->sg = NULL;
|
|
|
|
urb->num_sgs = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
usb_free_urb(urb);
|
|
|
|
}
|
|
|
|
if (!list_empty(&priv->list))
|
|
|
|
list_del(&priv->list);
|
|
|
|
if (priv->sgl)
|
|
|
|
sgl_free(priv->sgl);
|
|
|
|
kfree(priv->urbs);
|
|
|
|
kmem_cache_free(stub_priv_cache, priv);
|
|
|
|
}
|
|
|
|
|
2008-07-10 04:56:51 +08:00
|
|
|
static struct stub_priv *stub_priv_pop(struct stub_device *sdev)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
|
|
|
struct stub_priv *priv;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&sdev->priv_lock, flags);
|
|
|
|
|
|
|
|
priv = stub_priv_pop_from_listhead(&sdev->priv_init);
|
2011-05-20 12:36:58 +08:00
|
|
|
if (priv)
|
|
|
|
goto done;
|
2008-07-10 04:56:51 +08:00
|
|
|
|
|
|
|
priv = stub_priv_pop_from_listhead(&sdev->priv_tx);
|
2011-05-20 12:36:58 +08:00
|
|
|
if (priv)
|
|
|
|
goto done;
|
2008-07-10 04:56:51 +08:00
|
|
|
|
|
|
|
priv = stub_priv_pop_from_listhead(&sdev->priv_free);
|
|
|
|
|
2011-05-20 12:36:58 +08:00
|
|
|
done:
|
2008-07-10 04:56:51 +08:00
|
|
|
spin_unlock_irqrestore(&sdev->priv_lock, flags);
|
2011-05-20 12:36:58 +08:00
|
|
|
|
|
|
|
return priv;
|
2008-07-10 04:56:51 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void stub_device_cleanup_urbs(struct stub_device *sdev)
|
|
|
|
{
|
|
|
|
struct stub_priv *priv;
|
usbip: Implement SG support to vhci-hcd and stub driver
There are bugs on vhci with usb 3.0 storage device. In USB, each SG
list entry buffer should be divisible by the bulk max packet size.
But with native SG support, this problem doesn't matter because the
SG buffer is treated as contiguous buffer. But without native SG
support, USB storage driver breaks SG list into several URBs and the
error occurs because of a buffer size of URB that cannot be divided
by the bulk max packet size. The error situation is as follows.
When USB Storage driver requests 31.5 KB data and has SG list which
has 3584 bytes buffer followed by 7 4096 bytes buffer for some
reason. USB Storage driver splits this SG list into several URBs
because VHCI doesn't support SG and sends them separately. So the
first URB buffer size is 3584 bytes. When receiving data from device,
USB 3.0 device sends data packet of 1024 bytes size because the max
packet size of BULK pipe is 1024 bytes. So device sends 4096 bytes.
But the first URB buffer has only 3584 bytes buffer size. So host
controller terminates the transfer even though there is more data to
receive. So, vhci needs to support SG transfer to prevent this error.
In this patch, vhci supports SG regardless of whether the server's
host controller supports SG or not, because stub driver splits SG
list into several URBs if the server's host controller doesn't
support SG.
To support SG, vhci sets URB_DMA_MAP_SG flag in urb->transfer_flags
if URB has SG list and this flag will tell stub driver to use SG
list. After receiving urb from stub driver, vhci clear URB_DMA_MAP_SG
flag to avoid unnecessary DMA unmapping in HCD.
vhci sends each SG list entry to stub driver. Then, stub driver sees
the total length of the buffer and allocates SG table and pages
according to the total buffer length calling sgl_alloc(). After stub
driver receives completed URB, it again sends each SG list entry to
vhci.
If the server's host controller doesn't support SG, stub driver
breaks a single SG request into several URBs and submits them to
the server's host controller. When all the split URBs are completed,
stub driver reassembles the URBs into a single return command and
sends it to vhci.
Moreover, in the situation where vhci supports SG, but stub driver
does not, or vice versa, usbip works normally. Because there is no
protocol modification, there is no problem in communication between
server and client even if the one has a kernel without SG support.
In the case of vhci supports SG and stub driver doesn't, because
vhci sends only the total length of the buffer to stub driver as
it did before the patch applied, stub driver only needs to allocate
the required length of buffers using only kmalloc() regardless of
whether vhci supports SG or not. But stub driver has to allocate
buffer with kmalloc() as much as the total length of SG buffer which
is quite huge when vhci sends SG request, so it has overhead in
buffer allocation in this situation.
If stub driver needs to send data buffer to vhci because of IN pipe,
stub driver also sends only total length of buffer as metadata and
then sends real data as vhci does. Then vhci receive data from stub
driver and store it to the corresponding buffer of SG list entry.
And for the case of stub driver supports SG and vhci doesn't, since
the USB storage driver checks that vhci doesn't support SG and sends
the request to stub driver by splitting the SG list into multiple
URBs, stub driver allocates a buffer for each URB with kmalloc() as
it did before this patch.
* Test environment
Test uses two difference machines and two different kernel version
to make mismatch situation between the client and the server where
vhci supports SG, but stub driver does not, or vice versa. All tests
are conducted in both full SG support that both vhci and stub support
SG and half SG support that is the mismatch situation. Test kernel
version is 5.3-rc6 with commit "usb: add a HCD_DMA flag instead of
guestimating DMA capabilities" to avoid unnecessary DMA mapping and
unmapping.
- Test kernel version
- 5.3-rc6 with SG support
- 5.1.20-200.fc29.x86_64 without SG support
* SG support test
- Test devices
- Super-speed storage device - SanDisk Ultra USB 3.0
- High-speed storage device - SMI corporation USB 2.0 flash drive
- Test description
Test read and write operation of mass storage device that uses the
BULK transfer. In test, the client reads and writes files whose size
is over 1G and it works normally.
* Regression test
- Test devices
- Super-speed device - Logitech Brio webcam
- High-speed device - Logitech C920 HD Pro webcam
- Full-speed device - Logitech bluetooth mouse
- Britz BR-Orion speaker
- Low-speed device - Logitech wired mouse
- Test description
Moving and click test for mouse. To test the webcam, use gnome-cheese.
To test the speaker, play music and video on the client. All works
normally.
* VUDC compatibility test
VUDC also works well with this patch. Tests are done with two USB
gadget created by CONFIGFS USB gadget. Both use the BULK pipe.
1. Serial gadget
2. Mass storage gadget
- Serial gadget test
Serial gadget on the host sends and receives data using cat command
on the /dev/ttyGS<N>. The client uses minicom to communicate with
the serial gadget.
- Mass storage gadget test
After connecting the gadget with vhci, use "dd" to test read and
write operation on the client side.
Read - dd if=/dev/sd<N> iflag=direct of=/dev/null bs=1G count=1
Write - dd if=<my file path> iflag=direct of=/dev/sd<N> bs=1G count=1
Signed-off-by: Suwan Kim <suwan.kim027@gmail.com>
Acked-by: Shuah khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20190828032741.12234-1-suwan.kim027@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-28 11:27:41 +08:00
|
|
|
int i;
|
2008-07-10 04:56:51 +08:00
|
|
|
|
2017-12-19 08:23:37 +08:00
|
|
|
dev_dbg(&sdev->udev->dev, "Stub device cleaning up urbs\n");
|
2008-07-10 04:56:51 +08:00
|
|
|
|
|
|
|
while ((priv = stub_priv_pop(sdev))) {
|
usbip: Implement SG support to vhci-hcd and stub driver
There are bugs on vhci with usb 3.0 storage device. In USB, each SG
list entry buffer should be divisible by the bulk max packet size.
But with native SG support, this problem doesn't matter because the
SG buffer is treated as contiguous buffer. But without native SG
support, USB storage driver breaks SG list into several URBs and the
error occurs because of a buffer size of URB that cannot be divided
by the bulk max packet size. The error situation is as follows.
When USB Storage driver requests 31.5 KB data and has SG list which
has 3584 bytes buffer followed by 7 4096 bytes buffer for some
reason. USB Storage driver splits this SG list into several URBs
because VHCI doesn't support SG and sends them separately. So the
first URB buffer size is 3584 bytes. When receiving data from device,
USB 3.0 device sends data packet of 1024 bytes size because the max
packet size of BULK pipe is 1024 bytes. So device sends 4096 bytes.
But the first URB buffer has only 3584 bytes buffer size. So host
controller terminates the transfer even though there is more data to
receive. So, vhci needs to support SG transfer to prevent this error.
In this patch, vhci supports SG regardless of whether the server's
host controller supports SG or not, because stub driver splits SG
list into several URBs if the server's host controller doesn't
support SG.
To support SG, vhci sets URB_DMA_MAP_SG flag in urb->transfer_flags
if URB has SG list and this flag will tell stub driver to use SG
list. After receiving urb from stub driver, vhci clear URB_DMA_MAP_SG
flag to avoid unnecessary DMA unmapping in HCD.
vhci sends each SG list entry to stub driver. Then, stub driver sees
the total length of the buffer and allocates SG table and pages
according to the total buffer length calling sgl_alloc(). After stub
driver receives completed URB, it again sends each SG list entry to
vhci.
If the server's host controller doesn't support SG, stub driver
breaks a single SG request into several URBs and submits them to
the server's host controller. When all the split URBs are completed,
stub driver reassembles the URBs into a single return command and
sends it to vhci.
Moreover, in the situation where vhci supports SG, but stub driver
does not, or vice versa, usbip works normally. Because there is no
protocol modification, there is no problem in communication between
server and client even if the one has a kernel without SG support.
In the case of vhci supports SG and stub driver doesn't, because
vhci sends only the total length of the buffer to stub driver as
it did before the patch applied, stub driver only needs to allocate
the required length of buffers using only kmalloc() regardless of
whether vhci supports SG or not. But stub driver has to allocate
buffer with kmalloc() as much as the total length of SG buffer which
is quite huge when vhci sends SG request, so it has overhead in
buffer allocation in this situation.
If stub driver needs to send data buffer to vhci because of IN pipe,
stub driver also sends only total length of buffer as metadata and
then sends real data as vhci does. Then vhci receive data from stub
driver and store it to the corresponding buffer of SG list entry.
And for the case of stub driver supports SG and vhci doesn't, since
the USB storage driver checks that vhci doesn't support SG and sends
the request to stub driver by splitting the SG list into multiple
URBs, stub driver allocates a buffer for each URB with kmalloc() as
it did before this patch.
* Test environment
Test uses two difference machines and two different kernel version
to make mismatch situation between the client and the server where
vhci supports SG, but stub driver does not, or vice versa. All tests
are conducted in both full SG support that both vhci and stub support
SG and half SG support that is the mismatch situation. Test kernel
version is 5.3-rc6 with commit "usb: add a HCD_DMA flag instead of
guestimating DMA capabilities" to avoid unnecessary DMA mapping and
unmapping.
- Test kernel version
- 5.3-rc6 with SG support
- 5.1.20-200.fc29.x86_64 without SG support
* SG support test
- Test devices
- Super-speed storage device - SanDisk Ultra USB 3.0
- High-speed storage device - SMI corporation USB 2.0 flash drive
- Test description
Test read and write operation of mass storage device that uses the
BULK transfer. In test, the client reads and writes files whose size
is over 1G and it works normally.
* Regression test
- Test devices
- Super-speed device - Logitech Brio webcam
- High-speed device - Logitech C920 HD Pro webcam
- Full-speed device - Logitech bluetooth mouse
- Britz BR-Orion speaker
- Low-speed device - Logitech wired mouse
- Test description
Moving and click test for mouse. To test the webcam, use gnome-cheese.
To test the speaker, play music and video on the client. All works
normally.
* VUDC compatibility test
VUDC also works well with this patch. Tests are done with two USB
gadget created by CONFIGFS USB gadget. Both use the BULK pipe.
1. Serial gadget
2. Mass storage gadget
- Serial gadget test
Serial gadget on the host sends and receives data using cat command
on the /dev/ttyGS<N>. The client uses minicom to communicate with
the serial gadget.
- Mass storage gadget test
After connecting the gadget with vhci, use "dd" to test read and
write operation on the client side.
Read - dd if=/dev/sd<N> iflag=direct of=/dev/null bs=1G count=1
Write - dd if=<my file path> iflag=direct of=/dev/sd<N> bs=1G count=1
Signed-off-by: Suwan Kim <suwan.kim027@gmail.com>
Acked-by: Shuah khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20190828032741.12234-1-suwan.kim027@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-28 11:27:41 +08:00
|
|
|
for (i = 0; i < priv->num_urbs; i++)
|
|
|
|
usb_kill_urb(priv->urbs[i]);
|
2008-07-10 04:56:51 +08:00
|
|
|
|
usbip: Implement SG support to vhci-hcd and stub driver
There are bugs on vhci with usb 3.0 storage device. In USB, each SG
list entry buffer should be divisible by the bulk max packet size.
But with native SG support, this problem doesn't matter because the
SG buffer is treated as contiguous buffer. But without native SG
support, USB storage driver breaks SG list into several URBs and the
error occurs because of a buffer size of URB that cannot be divided
by the bulk max packet size. The error situation is as follows.
When USB Storage driver requests 31.5 KB data and has SG list which
has 3584 bytes buffer followed by 7 4096 bytes buffer for some
reason. USB Storage driver splits this SG list into several URBs
because VHCI doesn't support SG and sends them separately. So the
first URB buffer size is 3584 bytes. When receiving data from device,
USB 3.0 device sends data packet of 1024 bytes size because the max
packet size of BULK pipe is 1024 bytes. So device sends 4096 bytes.
But the first URB buffer has only 3584 bytes buffer size. So host
controller terminates the transfer even though there is more data to
receive. So, vhci needs to support SG transfer to prevent this error.
In this patch, vhci supports SG regardless of whether the server's
host controller supports SG or not, because stub driver splits SG
list into several URBs if the server's host controller doesn't
support SG.
To support SG, vhci sets URB_DMA_MAP_SG flag in urb->transfer_flags
if URB has SG list and this flag will tell stub driver to use SG
list. After receiving urb from stub driver, vhci clear URB_DMA_MAP_SG
flag to avoid unnecessary DMA unmapping in HCD.
vhci sends each SG list entry to stub driver. Then, stub driver sees
the total length of the buffer and allocates SG table and pages
according to the total buffer length calling sgl_alloc(). After stub
driver receives completed URB, it again sends each SG list entry to
vhci.
If the server's host controller doesn't support SG, stub driver
breaks a single SG request into several URBs and submits them to
the server's host controller. When all the split URBs are completed,
stub driver reassembles the URBs into a single return command and
sends it to vhci.
Moreover, in the situation where vhci supports SG, but stub driver
does not, or vice versa, usbip works normally. Because there is no
protocol modification, there is no problem in communication between
server and client even if the one has a kernel without SG support.
In the case of vhci supports SG and stub driver doesn't, because
vhci sends only the total length of the buffer to stub driver as
it did before the patch applied, stub driver only needs to allocate
the required length of buffers using only kmalloc() regardless of
whether vhci supports SG or not. But stub driver has to allocate
buffer with kmalloc() as much as the total length of SG buffer which
is quite huge when vhci sends SG request, so it has overhead in
buffer allocation in this situation.
If stub driver needs to send data buffer to vhci because of IN pipe,
stub driver also sends only total length of buffer as metadata and
then sends real data as vhci does. Then vhci receive data from stub
driver and store it to the corresponding buffer of SG list entry.
And for the case of stub driver supports SG and vhci doesn't, since
the USB storage driver checks that vhci doesn't support SG and sends
the request to stub driver by splitting the SG list into multiple
URBs, stub driver allocates a buffer for each URB with kmalloc() as
it did before this patch.
* Test environment
Test uses two difference machines and two different kernel version
to make mismatch situation between the client and the server where
vhci supports SG, but stub driver does not, or vice versa. All tests
are conducted in both full SG support that both vhci and stub support
SG and half SG support that is the mismatch situation. Test kernel
version is 5.3-rc6 with commit "usb: add a HCD_DMA flag instead of
guestimating DMA capabilities" to avoid unnecessary DMA mapping and
unmapping.
- Test kernel version
- 5.3-rc6 with SG support
- 5.1.20-200.fc29.x86_64 without SG support
* SG support test
- Test devices
- Super-speed storage device - SanDisk Ultra USB 3.0
- High-speed storage device - SMI corporation USB 2.0 flash drive
- Test description
Test read and write operation of mass storage device that uses the
BULK transfer. In test, the client reads and writes files whose size
is over 1G and it works normally.
* Regression test
- Test devices
- Super-speed device - Logitech Brio webcam
- High-speed device - Logitech C920 HD Pro webcam
- Full-speed device - Logitech bluetooth mouse
- Britz BR-Orion speaker
- Low-speed device - Logitech wired mouse
- Test description
Moving and click test for mouse. To test the webcam, use gnome-cheese.
To test the speaker, play music and video on the client. All works
normally.
* VUDC compatibility test
VUDC also works well with this patch. Tests are done with two USB
gadget created by CONFIGFS USB gadget. Both use the BULK pipe.
1. Serial gadget
2. Mass storage gadget
- Serial gadget test
Serial gadget on the host sends and receives data using cat command
on the /dev/ttyGS<N>. The client uses minicom to communicate with
the serial gadget.
- Mass storage gadget test
After connecting the gadget with vhci, use "dd" to test read and
write operation on the client side.
Read - dd if=/dev/sd<N> iflag=direct of=/dev/null bs=1G count=1
Write - dd if=<my file path> iflag=direct of=/dev/sd<N> bs=1G count=1
Signed-off-by: Suwan Kim <suwan.kim027@gmail.com>
Acked-by: Shuah khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20190828032741.12234-1-suwan.kim027@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-28 11:27:41 +08:00
|
|
|
stub_free_priv_and_urb(priv);
|
2008-07-10 04:56:51 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-05-20 12:36:59 +08:00
|
|
|
static int __init usbip_host_init(void)
|
2008-07-10 04:56:51 +08:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2012-01-26 02:46:32 +08:00
|
|
|
init_busid_table();
|
2011-05-20 12:37:00 +08:00
|
|
|
|
2012-01-26 02:46:32 +08:00
|
|
|
stub_priv_cache = KMEM_CACHE(stub_priv, SLAB_HWCACHE_ALIGN);
|
2008-07-10 04:56:51 +08:00
|
|
|
if (!stub_priv_cache) {
|
2011-05-20 12:36:58 +08:00
|
|
|
pr_err("kmem_cache_create failed\n");
|
2008-07-10 04:56:51 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
2014-01-24 05:12:29 +08:00
|
|
|
ret = usb_register_device_driver(&stub_driver, THIS_MODULE);
|
2013-09-10 13:14:07 +08:00
|
|
|
if (ret) {
|
2011-05-20 07:47:32 +08:00
|
|
|
pr_err("usb_register failed %d\n", ret);
|
2011-05-20 12:36:58 +08:00
|
|
|
goto err_usb_register;
|
2008-07-10 04:56:51 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
ret = driver_create_file(&stub_driver.drvwrap.driver,
|
|
|
|
&driver_attr_match_busid);
|
2013-09-10 13:14:07 +08:00
|
|
|
if (ret) {
|
2011-05-20 12:36:58 +08:00
|
|
|
pr_err("driver_create_file failed\n");
|
|
|
|
goto err_create_file;
|
2008-07-10 04:56:51 +08:00
|
|
|
}
|
|
|
|
|
2014-03-08 20:53:33 +08:00
|
|
|
ret = driver_create_file(&stub_driver.drvwrap.driver,
|
|
|
|
&driver_attr_rebind);
|
|
|
|
if (ret) {
|
|
|
|
pr_err("driver_create_file failed\n");
|
|
|
|
goto err_create_file;
|
|
|
|
}
|
|
|
|
|
2008-07-10 04:56:51 +08:00
|
|
|
return ret;
|
2011-05-20 12:36:58 +08:00
|
|
|
|
|
|
|
err_create_file:
|
2014-01-24 05:12:29 +08:00
|
|
|
usb_deregister_device_driver(&stub_driver);
|
2011-05-20 12:36:58 +08:00
|
|
|
err_usb_register:
|
2008-07-10 04:56:51 +08:00
|
|
|
kmem_cache_destroy(stub_priv_cache);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2011-05-20 12:36:59 +08:00
|
|
|
static void __exit usbip_host_exit(void)
|
2008-07-10 04:56:51 +08:00
|
|
|
{
|
|
|
|
driver_remove_file(&stub_driver.drvwrap.driver,
|
|
|
|
&driver_attr_match_busid);
|
|
|
|
|
2014-03-08 20:53:33 +08:00
|
|
|
driver_remove_file(&stub_driver.drvwrap.driver,
|
|
|
|
&driver_attr_rebind);
|
|
|
|
|
2008-07-10 04:56:51 +08:00
|
|
|
/*
|
|
|
|
* deregister() calls stub_disconnect() for all devices. Device
|
|
|
|
* specific data is cleared in stub_disconnect().
|
|
|
|
*/
|
2014-01-24 05:12:29 +08:00
|
|
|
usb_deregister_device_driver(&stub_driver);
|
2008-07-10 04:56:51 +08:00
|
|
|
|
2018-05-01 06:17:20 +08:00
|
|
|
/* initiate scan to attach devices */
|
|
|
|
stub_device_rebind();
|
|
|
|
|
2008-07-10 04:56:51 +08:00
|
|
|
kmem_cache_destroy(stub_priv_cache);
|
|
|
|
}
|
|
|
|
|
2011-05-20 12:36:59 +08:00
|
|
|
module_init(usbip_host_init);
|
|
|
|
module_exit(usbip_host_exit);
|
2008-07-10 04:56:51 +08:00
|
|
|
|
|
|
|
MODULE_AUTHOR(DRIVER_AUTHOR);
|
|
|
|
MODULE_DESCRIPTION(DRIVER_DESC);
|
|
|
|
MODULE_LICENSE("GPL");
|