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_map_urb_for_dma() 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.
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.
Alan fixed vhci bug with the USB 3.0 storage device by modifying
USB storage driver.
("usb-storage: Set virt_boundary_mask to avoid SG overflows")
But the fundamental solution of it is to add SG support to vhci.
This patch works well with the USB 3.0 storage devices without Alan's
patch, and we can revert Alan's patch if it causes some troubles.
Suwan Kim (2):
usbip: Skip DMA mapping and unmapping for urb at vhci
usbip: Implement SG support to vhci-hcd and stub driver
drivers/usb/usbip/stub.h | 7 +-
drivers/usb/usbip/stub_main.c | 57 ++++++---
drivers/usb/usbip/stub_rx.c | 204 ++++++++++++++++++++++---------
drivers/usb/usbip/stub_tx.c | 99 +++++++++++----
drivers/usb/usbip/usbip_common.c | 59 ++++++---
drivers/usb/usbip/vhci_hcd.c | 34 +++++-
drivers/usb/usbip/vhci_tx.c | 63 ++++++++--
7 files changed, 396 insertions(+), 127 deletions(-)
--
2.20.1
FYI, I think my
"usb: add a HCD_DMA flag instead of guestimating DMA capabilities"
is the proper core fix for what your patch 1 works around, as the USB
core should not assume DMA capabilities based on the presence of a DMA
mask.
On Wed, Aug 14, 2019 at 06:19:51AM -0700, Christoph Hellwig wrote:
> FYI, I think my
>
> "usb: add a HCD_DMA flag instead of guestimating DMA capabilities"
>
> is the proper core fix for what your patch 1 works around, as the USB
> core should not assume DMA capabilities based on the presence of a DMA
> mask.
I agree. Let's wait for Christoph's series to be applied before taking
this one.
thanks,
greg k-h
On 8/15/19 7:23 AM, Greg KH wrote:
> On Wed, Aug 14, 2019 at 06:19:51AM -0700, Christoph Hellwig wrote:
>> FYI, I think my
>>
>> "usb: add a HCD_DMA flag instead of guestimating DMA capabilities"
>>
>> is the proper core fix for what your patch 1 works around, as the USB
>> core should not assume DMA capabilities based on the presence of a DMA
>> mask.
>
> I agree. Let's wait for Christoph's series to be applied before taking
> this one.
>
Great. Thanks you both looking at these. Makes sense.
thanks,
-- Shuah
On Thu, Aug 15, 2019 at 08:10:49AM -0600, shuah wrote:
> On 8/15/19 7:23 AM, Greg KH wrote:
> > On Wed, Aug 14, 2019 at 06:19:51AM -0700, Christoph Hellwig wrote:
> > > FYI, I think my
> > >
> > > "usb: add a HCD_DMA flag instead of guestimating DMA capabilities"
> > >
> > > is the proper core fix for what your patch 1 works around, as the USB
> > > core should not assume DMA capabilities based on the presence of a DMA
> > > mask.
> >
> > I agree. Let's wait for Christoph's series to be applied before taking
> > this one.
> >
>
> Great. Thanks you both looking at these. Makes sense.
Ok. Then I will drop the patch 1 and leave vhci flags without
including the HCD_DMA flag to skip dma mapping.
BTW, in my patch 2, I set URB_DMA_MAP_SG flag in
vhci_map_urb_for_dma() of patch 1 to tell the server to use SG.
I will fix it by setting URB_DMA_MAP_SG flag in other place and
resend v6. Is it ok?
Regards
Suwan Kim