RE: [Xen-devel] USB virt status --- Help please!!!

[Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

> > I'm in the middle of debugging a problem where dom0 reboots 
> > when flushing a big file to the USB key.  I didn't manage to 
> > find a serial cable for a serial console this evening so I 
> > don't have much to go on yet.
> 
> You could try 'noreboot' and stick to a text mode.

Thanks, yes this worked.

It turns out that dom0 is bombing out in dma_map_single
(arch/xen/i386/kernel/pci-dma.c) with a failure of
range_straddles_page_boundary and if I use swiotlb=force on the command
line as suggested by the printk then it all seems to work fine.

Looking at the kernel documentation for the DMA api I get the impression
that dma_map_single ought to work across page boundaries provided the
pages are contiguous in physical memory.  Given that the code seems to
work writing and verifying large random files with swiotlb=force I think
I'm probably not getting the addresses wrong and I'm assuming that if
the memory was good enough for the USB driver in the FE it ought to be
good enough for the USB driver in the BE.

So, to me this looks like a bug in the xen implementation of
dma_map_single which I think ought to not fail just because of crossing
a page boundary but only if the memory is discontiguous.

But, I don't really know enough about the memory model to know if this
is right.

So, I need to know what I ought to be doing with the USB memory mapping.

Currently, I'm taking the FE pointer to the memory buffer and creating a
grant reference for each page spanned by the request then mapping them
into the BE address space in an empty page range taken from the balloon
driver.  This is the same as the block driver where I copied the code
from.

Then I pass the address of the start of the buffer in the empty page
range in the URB to the usb core.

Is this the right approach? Is the check in dma_map_single overzealous?

Harry.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel