* Alexander Duyck (alexander.h.duyck@intel.com) wrote:
quoted text
> 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).

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html