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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 09.11.12 at 10:40, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>> On 09.11.12 at 10:16, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>> On Fri, 2012-11-09 at 09:03 +0000, Jan Beulich wrote:
>>> >>> On 12.10.12 at 12:28, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
>>> > The following patch causes fairly large packet loss when transmitting
>>> > from dom0 to the physical network, at least with my tg3 hardware, but I
>>> > assume it can impact anything which uses this interface.
>>> > 
>>> > I suspect that the issue is that the compound pages allocated in this
>>> > way are not backed by contiguous mfns and so things fall apart when the
>>> > driver tries to do DMA.
>>> 
>>> Has this seen any sort of resolution yet? Despite having forced
>>> NETDEV_FRAG_PAGE_MAX_ORDER to zero for Xen (following
>>> your suggested patch, Ian), and with a different NIC (e1000e
>>> driven) I'm seeing similar packet loss/corruption on transmits,
>>> and only if running a debug hypervisor (in a non-debug one,
>>> MFNs are largely contiguous, so this issue should be observable
>>> there only very rarely).
>> 
>> I think Konrad is still looking into the underlying swiotlb issue.
>> 
>> If you want to go with the workaround then there is another order>0 to
>> frob in net/core/sock.c
>> #define SKB_FRAG_PAGE_ORDER  get_order(32768)
>> which might help.
> 
> Thanks, that indeed helped. And gives me food for thought as
> well, since this should - if anything at all - be a performance
> improvement, not a something affecting correctness.

Okay, one problem in the pv-ops case seems pretty obvious:
dma_capable() does (potentially cross-page) arithmetic on a
dma_addr_t value, ignoring dis-contiguity altogether. Specifically
its first use in swiotlb_map_page() and its only use in
swiotlb_map_sg_attrs() are problematic.

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.

Jan


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