| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] PCI passthrough issue
On Tue, 2011-02-01 at 12:17 +0000, Jean Baptiste Favre wrote:
> > 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?
> I made all tests with Marvell NIC (driver sky2).
> I don't know if the same behaviour occurs with another NIC type. I'll
> try with an Intel one (I've a dual port Intel NIC, so I could
> passthrough only one port)
I was confused -- the quoted list of passthrough devices including Intel
NICs I saw was from Konrad not you. It would still be interesting to
confirm if the issue is specific to the particular NIC or not.
> > 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?
> I made tests with both OpenWRT and Debian Squeeze.
> Had problems to compile OpenWRT kernel in 64bits :)
> I tested Debian Squeeze with 2.6.37 kernel from experimental (because of
> Xen PCI Frontend integration. Not sure it has been backported into 2.6.32).
The PCI frontend is in the xen.git xen/stable-2.6.32.x branch but not in
mainline 2.6.32.y stable branches.
> > If you restrict dom0 to >256MB but <512MB (using dom0_mem= on hypervisor
> > command line) does the NIC work correctly in non-passedthrough form?
> My Xen hypervisor commandline is as follow:
> placeholder dom0_mem=256M dom0_max_vcpus=1 dom0_vcpus_pin loglvl=all
> guest_loglvl=all com1=115200,8n1 console=com1
>
> Everything works great without passthrough, but my dom0 is 64bits which
> may explain that (I do have this strange behaviour only with 32bits
> kernels).
I don't suppose you could try installing a 32 bit OS in dom0? (e.g. as a
skanky hack you might fit something into your existing swap
partition ;-))
> I did not tried changing dom0_mem param.
>
> > Similarly does the kernel running native with mem= cause the failure?
> Not sure I understand what you mean here.
I meant to run the system as a native (non-Xen) system and use the
kernels mem= command line parameter to restrict the system to the
problematic amounts of memory. Really just trying to verify if something
is up specifically due to Xen or not. Probably needs a 32 bit
user/kernel to be a useful experiment.
What do "ifconfig" or "ethtool -S" show for the device after some
failures. Do any of the numbers increment inline with the dropped
frames?
Perhaps interestingly 85 bytes, plus the ICMP, IP and Ethernet header
sizes is something around 128 bytes (depending on options etc). This is
pure numerology but I notice that sky2 has a copybreak parameter
("Receive copy threshold") which defaults to 128. I think it would be
worth trying 64 and 256.
Are you able to see any traffic with tcpdump, either in guest and/or
from another host (may require switch configuration to allow it to see
the traffic). e.g. do you see the ICMP Echo Request but not the Echo
Response or do you see nothing at all etc.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home