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:06:18 +0100 Message-ID: <4D4883DA.5030708@jbfavre.org> References: <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> <20110201193743.GA18656@dumpdata.com> Reply-To: xen-devel@lists.xensource.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20110201193743.GA18656@dumpdata.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 20:37, Konrad Rzeszutek Wilk a =E9crit : > On Tue, Feb 01, 2011 at 04:23:09PM +0000, Ian Campbell wrote: >> 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. >> >> 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 R= AM >> artificially limited via the mem=3D kernel command in option, this wil= l >> 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=3D=3D0) it hits a code path which u= ses >> 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 i= t >> seems like the later path is broken somehow. If the issue does turn ou= t >=20 > It could also have gotten the direction reverted (the 3c5XX code had it > wrong at some point so..). Might make sense to compile the kernel with > CONFIG_DMA_API_DEBUG which is good at detecting these issues. >=20 >> 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 fo= r >> 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 >=20 > swiotlb=3Dforce will do it. I already use this option as specified on wiki: http://wiki.xen.org/xenwiki/XenPCIpassthrough >> should try first? >=20 > I think we have a good lead. So let's go for testing that way :) >>> It seems that adding this options in /etc/modprobe.d/sky2.conf does n= ot >>> work, neither using /etc/modules >=20 > You could just pass as Linux kernel parameter 'sky2.copybreak=3D0'. But= I am > not sure if that stays if the 'sky2' driver is compiled as module. According to Ian, this will work only with statically compiled driver.