From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean Baptiste Favre Subject: Re: PCI passthrough issue Date: Tue, 01 Feb 2011 23:04:05 +0100 Message-ID: <4D488355.8010706@jbfavre.org> References: <4D2E28C5.30203@jbfavre.org> <4D2EE1DE.5070006@jbfavre.org> <4D2F5009.2090701@jbfavre.org> <20110113201922.GA20494@dumpdata.com> <4D2F6431.8030606@jbfavre.org> <20110114145350.GB7371@dumpdata.com> <4D30DC5A.9080303@jbfavre.org> <4D340504.7020203@jbfavre.org> <4D344AF4.80301@jbfavre.org> <4D3AB003.3040603@jbfavre.org> <20110127202755.GA4194@dumpdata.com> <4D41E7EE.4060502@jbfavre.org> <4D42E520.9020107@jbfavre.org> <1296560086.13091.131.camel@zakaz.uk.xensource.com> <4D47F9CF.2040107@jbfavre.org> <1296566401.13091.171.camel@zakaz.uk.xensource.com> <4D4814CE.5050303@jbfavre.org> <1296569931.13091.194.camel@zakaz.uk.xensource.com> <4D48234F.2020907@jbfavre.org> <4D4828D9.6090601@jbfavre.org> <1296577389.13091.288.camel@zakaz.uk.xensource.com> Reply-To: xen-devel@lists.xensource.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <1296577389.13091.288.camel@zakaz.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Le 01/02/2011 17:23, Ian Campbell a =C3=A9crit : > 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=3D0 (no packet copied) >> - ping -s 86 10.0.0.1 (works) >> >> So it's clearly related to that option. >=20 > Awesome! >=20 >> Now the question: what am I supposed to do ? >=20 > I think the next step is to try and reproduce on native 32 bit, with RA= M > artificially limited via the mem=3D 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=3D=3D0) it hits a code path which us= es > 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. >=20 > 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 w= e > should try first? >=20 >> It seems that adding this options in /etc/modprobe.d/sky2.conf does no= t >> work, neither using /etc/modules >=20 > That will be a userspace issue in your distro, perhaps with openwrt the= y > 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