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

On Tue, 2011-02-01 at 23:01 +0000, Jean Baptiste Favre wrote:
> Le 01/02/2011 20:37, Konrad Rzeszutek Wilk a écrit :
> > 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=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
> > 
> > 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.
> > 
> >> 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
> > 
> > swiotlb=force 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=256M swiotlb=force"
> 
> 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 ?

It certainly seems that way. I'm not 100% sure that swiotlb=force will
have actually made the driver use the swiotlb, it may just have forced
the swiotlb to be allocated. Konrad?

> 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 ?

Yes please.

> If so, what tools will I need to get debug informations ?

Uh, Konrad?

Ian.


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

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