Re: [Xen-devel] PCI passthrough issue

[Jean Baptiste Favre <xen-devel@xxxxxxxxxxx>]

Hello,


Le 01/02/2011 14:20, Ian Campbell a Ãcrit :
> 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.
Yes, that's why I tried with 2.6.37 from experimental, after Pasi's
answer to one of my question on the maillist one month ago or so.

> >> 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 could try, but that would means breaking my test platform. Let's say I
prefer complete other tests before :)

> > 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.
Ah ok. But then, running 32bits kernel with 64 bits OS will work ? (I
didn't know 64bits kernel worked with 32bits OS before Konrad told me)

> 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.
That's exactly the problem I faced with 256mb memory for my domU.
Outgoing packets reached my gateway (tcpdump saw them on it, as well as
replies) but incoming packets greater than 128bits were blocked
somewhere between Xen hypervisor and domU user space (where I was
listening traffic with tcpdump).

I didn't notice the copybreak from sky2. Where can I change it ? It
could be exactly what we're looking for from the beginning, couldn't it ?
How can I change it ?

> 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.
tcpdump tests have been done from my gateway and from domU.
On the GW: can see all incoming packets (whatever could be the size) and
send all replies.
On the DomU: can see all outgoing packets but only incoming ones shorter
than 128bytes (global size, means "ping -s85" and less)

Regards,
JB

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