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

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 11/09/12 2:48 PM >>>
>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,

Oh, right, I forgot that there's yet another clone of that code under 
drivers/xen/.

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

Indeed.

Jan


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