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 Fri, 2011-01-28 at 15:47 +0000, Jean Baptiste Favre wrote:
> Hello,
> I made some more tests today, still with 2.6.37 32bits kernel from
> Debian experimental, with various memory allocation value.
> 
> For each test, I make ping on my gateway with various packet size:
> ping -s15 10.0.0.1
> ping -s85 10.0.0.1
> ping -s86 10.0.0.1
> ping -s150 10.0.0.1
> 
> Results bellow:
> 
> - less than 256mb: works
> - between 256 and 512mb: ping greater than 85 bytes does not work
> - more than 512mb: works
> 
> I'm lost...

Me too, this really is the most inexplicable set of symptoms...

Does it work correctly with any other guest kernel, e.g. the
xen/stable-2.6.32.x branch from xen.git or maybe one of the old-style
Xen kernels?

The network device in use is one of the Intel NICs below? Any luck just
passing through that one device without all the others?

Previously you mentioned using a Marvell NIC, so I guess the failure is
independent of the NIC type?

Your userspace is still OpenWRT in these most recent tests? Is that some
sort of busybox based thing? Can you try with e.g. a regular Debian
guest userspace to rule out any funnyness from that end?

If you restrict dom0 to >256MB but <512MB (using dom0_mem= on hypervisor
command line) does the NIC work correctly in non-passedthrough form?
Similarly does the kernel running native with mem= cause the failure?

Bit of a long shot but are you able to try a 4.0.2-rc hypervisor+tools
and/or a 4.1.0-rc setup (not branched yet so still in xen-unstable.hg)?

Is the 10.0.0.1 address you are testing against a VM on the same host or
some sort of external entity?

Ian.

> Regards,
> JB
> 
> 
> Le 27/01/2011 22:47, Jean Baptiste Favre a écrit :
> > Hello Konrad,
> > 
> > Le 27/01/2011 21:27, Konrad Rzeszutek Wilk a écrit :
> >> On Sat, Jan 22, 2011 at 11:22:59AM +0100, Jean Baptiste Favre wrote:
> >>> Hello,
> >>> Last investigations show that I've the latest BIOS version for my
> >>> motherboard.
> >>> Do you need more tests, if yes which ones ?
> >>
> >> I tried it on my 2.6.32.27 (32-bit and 64-bit) and I am not seeing
> >> the failures you have. These are the devices I passed in:
> >>
> >> 00:00.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
> >> Controller #1 (rev 02)
> >> 00:00.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
> >> Controller #2 (rev 02)
> >> 00:00.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI 
> >> Controller #3 (rev 02)
> >> 00:00.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI 
> >> Controller #1 (rev 02)
> >> 00:01.1 Ethernet controller: Intel Corporation 82575EB Gigabit Network 
> >> Connection (rev 02)
> >> 00:02.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X 
> >> Fusion-MPT Dual Ultra320 SCSI (rev 07)
> >> 00:02.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X 
> >> Fusion-MPT Dual Ultra320 SCSI (rev 07)
> >> 00:03.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet 
> >> Controller (Copper) (rev 06)
> >>
> >> Granted the kernel I am using a jeremy/xen/stable-2.6.32.x so not sure
> >> how divergent from Debian or Debian Squeeze it is.
> >>
> >> How are you launching your guest? Do you something like this:
> >>
> >> kernel="/mnt/lab/2.6.32.27/vmlinuz"
> >> ramdisk="/mnt/lab/2.6.32.27/initramfs.cpio.gz"
> >> extra="console=hvc0 debug test=crashme iommu=soft"
> >> memory=1024
> >> maxmem=2048
> >> vcpus=4
> >> on_crash="preserve"
> >> pci= 
> >> ["00:1d.0","00:1d.1","00:1d.2","00:1d.7","0a:00.1","0000:06:01.1","0000:06:01.0",
> >>  "09:00.0"]
> >> vif = [ 'mac=00:0f:4b:00:00:68, bridge=switch' ]
> > 
> > Here is my domU config file:
> > ####################
> > kernel       = '/cluster/kernels/vmlinuz-2.6.37-trunk-686-bigmem'
> > ramdisk      = '/cluster/kernels/initrd.img-2.6.37-trunk-686-bigmem'
> > builder      = 'linux'
> > 
> > memory       = '256'
> > memory       = '512'
> > vcpus        = '1'
> > cpus         = '2'
> > localtime    = 0
> > serial       = 'pty'
> > 
> > disk         = [ 'drbd:xps-106,xvda,w' ]
> > 
> > on_poweroff  = 'destroy'
> > on_reboot    = 'restart'
> > on_crash     = 'restart'
> > 
> > extra = "root=/dev/mapper/xps--106-root ro iommu=soft swiotlb=force
> > console=hvc0 xencons=tty"
> > 
> > pci = [ '04:00.0' ]
> > 
> > name         = 'xps-106'
> > hostname     = 'xps-106.clichy.jbfavre.org'
> > ####################
> > 
> > As I privately told you, I made the tests you suggested and the result
> > is that problem occurs with 256mb of memory, but is solved with 512mb or
> > more.
> > 
> > Basically, what I find surprising is that with 256mb of memory, the max
> > size for incoming packets to be blocked is 128 bytes.
> > Makes me think about an unsigned integer or something like that, but I
> > don't have enough kernel knowledge to be more precise.
> > 
> > Regards,
> > JB
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> > 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



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

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