WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] PCI passthrough issue

To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] PCI passthrough issue
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Date: Tue, 1 Feb 2011 16:23:09 +0000
Cc: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
Delivery-date: Tue, 01 Feb 2011 08:23:45 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4D4828D9.6090601@xxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Citrix Systems, Inc.
References: <4D2E28C5.30203@xxxxxxxxxxx> <4D2EE1DE.5070006@xxxxxxxxxxx> <4D2F5009.2090701@xxxxxxxxxxx> <20110113201922.GA20494@xxxxxxxxxxxx> <4D2F6431.8030606@xxxxxxxxxxx> <20110114145350.GB7371@xxxxxxxxxxxx> <4D30DC5A.9080303@xxxxxxxxxxx> <4D340504.7020203@xxxxxxxxxxx> <4D344AF4.80301@xxxxxxxxxxx> <4D3AB003.3040603@xxxxxxxxxxx> <20110127202755.GA4194@xxxxxxxxxxxx> <4D41E7EE.4060502@xxxxxxxxxxx> <4D42E520.9020107@xxxxxxxxxxx> <1296560086.13091.131.camel@xxxxxxxxxxxxxxxxxxxxxx> <4D47F9CF.2040107@xxxxxxxxxxx> <1296566401.13091.171.camel@xxxxxxxxxxxxxxxxxxxxxx> <4D4814CE.5050303@xxxxxxxxxxx> <1296569931.13091.194.camel@xxxxxxxxxxxxxxxxxxxxxx> <4D48234F.2020907@xxxxxxxxxxx> <4D4828D9.6090601@xxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2011-02-01 at 15:38 +0000, Jean Baptiste Favre wrote:
> OK, just found it:
> after domU boot:
> - log in
> - ping -s 86 10.0.0.1 (fails)
> - rmmod sky2
> - modprobe sky2 copybreak=0 (no packet copied)
> - ping -s 86 10.0.0.1 (works)
> 
> So it's clearly related to that option.

Awesome!

> Now the question: what am I supposed to do ?

I think the next step is to try and reproduce on native 32 bit, with RAM
artificially limited via the mem= kernel command in option, this will
let us determine if this is a generic issue or is somehow Xen specific.

The main difference caused by the copybreak option is that for larger
frames (i.e. always when copybreak==0) it hits a code path which uses
pci_map_single and pci_map_page to access the received data. When len <
copybreak it takes a path which uses pci_dma_sync_single_for_cpu, so it
seems like the later path is broken somehow. If the issue does turn out
to be related to Xen then I think that points to the swiotlb code.

I assume you are not seeing "rx mapping error" in your domU dmesg? Did
you post a full guest console log at some point? Comparing the logs for
the 256MB, 398MB and 512MB guest RAM case might be useful.

Konrad, is there some way to force swiotlb use even for native to make
the native test cases more relevant? Or is there some other direction we
should try first?

> It seems that adding this options in /etc/modprobe.d/sky2.conf does not
> work, neither using /etc/modules

That will be a userspace issue in your distro, perhaps with openwrt they
are not expected to work that way.

Ian.



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