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
Subject: Re: [Xen-devel] PCI passthrough issue
From: Jean Baptiste Favre <xen-devel@xxxxxxxxxxx>
Date: Tue, 01 Feb 2011 23:04:05 +0100
Delivery-date: Tue, 01 Feb 2011 14:04:57 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1296577389.13091.288.camel@xxxxxxxxxxxxxxxxxxxxxx>
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>
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> <1296577389.13091.288.camel@xxxxxxxxxxxxxxxxxxxxxx>
Reply-to: xen-devel@xxxxxxxxxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101213 Lightning/1.0b2 Icedove/3.1.7
Le 01/02/2011 17:23, Ian Campbell a écrit :
> 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.
OK, so I'll install a 32bits Debian Squeeze with 2.6.37 32bits kernel to
check it.

> 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.
No sure I've ever posted that logs. But I can redo my tests :)

> 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.
All tests were done with Debian. As the module is included in initramfs
and not on domU, since I've no kernel installed in the domU, module is
loaded before system FS, so /etc/modprobe.d/sky2.conf is not taken into
account.
I think that the best solution here is to compile kernel with  static
sky2 driver inclusion and use kernel commandline to pass sky2 copybreak
option.

Regards,
JB

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

<Prev in Thread] Current Thread [Next in Thread>