Re: [Xen-devel] Dom0 physical networking/swiotlb/something issue in 3.7-rc1

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Fri, Nov 09, 2012 at 11:43:39AM +0000, Jan Beulich wrote:
> >>> On 09.11.12 at 11:36, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> > In the forward ported kernels, those two checks are however
> > accompanied by range_needs_mapping() (aka
> > range_straddles_page_boundary()) checks, which ought to
> > take care of this. There is brokenness there with the invocations
> > of gnttab_dma_map_page(), but only if the initial offset is at
> > least PAGE_SIZE - will have to check whether that occurs.
> 
> And indeed, fixing this also makes the problem go away when
> the allocation order doesn't get forced to zero. So presumably
> there's also only that one problem I had pointed out in pv-ops.

The pvops one has this in the map-page variant (xen_swiotlb_map_page):

351         if (dma_capable(dev, dev_addr, size) &&
352             !range_straddles_page_boundary(phys, size) && !swiotlb_force)
353                 return dev_addr;

and in the sg variant:

494                 if (swiotlb_force ||
495                     !dma_capable(hwdev, dev_addr, sg->length) ||
496                     range_straddles_page_boundary(paddr, sg->length)) {
497                         void *map = swiotlb_tbl_map_single(hwdev,

So I think that check is OK. There is no gnttab_dma_map_page call - so that
can't be the issue.

I did play with this a bit and wrote this little driver (see attached) that
forces allocation of large pages and it worked as expected on Xen-SWIOTLB.

But while doing this I found that the 'skge' driver is busted - it does not
even work on baremetal if you do 'iommu=soft swiotlb=force'. Since
Xen-SWIOTLB would occasionaly use the bounce-buffer  - and with greater than
0-page order - the bug in skge became more obvious. I hadn't narrowed down
where the issue is with skge.
> 
> Jan

Attachment: dma_test.c
Description: Text document

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel