From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean Baptiste Favre Subject: Re: PCI passthrough issue Date: Wed, 02 Feb 2011 00:01:33 +0100 Message-ID: <4D4890CD.7080009@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. OK, just performed native test. Installed 32bits Debian Squeeze, add 2.6.37 32bits kernel from experimental, setup grub with following options: "mem=3D256M swiotlb=3Dforce" Ping tests work whatever can be packet size. If I understood well what you explain to me, it's now clear that the problem is somewhat Xen related, isn't it ? I'll be able to continue any tests you want tomorrow. Do you still need me to compile domU kernel with "CONFIG_DMA_API_DEBUG" enabled ? If so, what tools will I need to get debug informations ? Now, it's time to sleep here in France :) (or I'll get killed by my girl friend :D ) Regards, JB