netdev - Re: igb VF allocation with quirk_i82576

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 22 Sep 2009 22:12:56 -0700
From:	Chris Wright <chrisw@...s-sol.org>
To:	Alexander Duyck <alexander.h.duyck@...el.com>
Cc:	Chris Wright <chrisw@...s-sol.org>,
	"Ronciak, John" <john.ronciak@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>
Subject: Re: igb VF allocation with quirk_i82576_sriov

* Alexander Duyck (alexander.h.duyck@...el.com) wrote:
> Chris Wright wrote:
>> Is this known to work?  During recent virt testing for upcoming Fedora 12,
>> a box w/out SR-IOV support in BIOS was using quirk to create VF BAR space,
>> VF allocation worked enough to assign a device to the guest, but igbvf
>> was not actually functioning properly in the guest.
>>
>> Is it worth debugging this further, or is it already a known issue?
>
> You could be experiencing one of a couple different issues.
>
> First when you say you started SR-IOV on a box w/out SR-IOV support I  
> assume you are using "pci=assign-busses" in order to reserve the bus  
> space for the VFs, is that correct?  Also while your system may not  
> support SR-IOV does it at least support VT-d?  Without VT-d support you  
> won't be able to assign a device to the guest.

VT-d was definitely there, as for the rest I'll have to ask the tester
for more details.  I just wanted to verify that it's a known working
combo before spending more time on it.

Regarding the bus numbering, I don't think there's a bus issue.
The PF+VFs all stay w/in same bus segment despite large offset and the
stride (IIRC, this was only device on bus 2, a dual port igb on .0 and .1.
the offset is 128 and stride is 2, so even w/ 8 VFs the max device would
be something like 2:11.7 or 2:12.0).

> My recommendations for further testing would be to test a VF on the host  
> kernel to see if that works.  If it does then you could also try direct  
> assigning an entire port to see if that works.  If the entire port  
> doesn't work then you probably don't have VT-d enabled.

Yeah, IIRC, igbvf at least loaded on the host (on the guest too, after
unbinding host driver).  I didn't get a chance to see if VF passed
traffic on the host, and from the report, it wasn't able to get a dhcp
address in the guest.  Will dig into it a bit more after plumbers.

thanks,
-chris
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html