[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Dom0 physical networking/swiotlb/something issue in 3.7-rc1
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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |