Hi Kevin, The issue with the BIOS is that it is not assigning resources/buses for SR-IOV. I'm not sure what tweaks would be needed in coreboot to fix it.
The lspci -vvv you sent must be after the enabling the workarounds since the buses/resources are populated. The reason why I was asking for it was to verify the bus/resource layout and things look like they are populated now. You would need your BIOS to configure things this way without the kernel workarounds to not need them. Thanks. - Alex On Tue, May 8, 2018 at 8:52 PM, Kevin Cody-Little <kcod...@gmail.com> wrote: > Alexander, > > > Thank you. I can report that those kernel options worked, and I can see > the change in bus numbers in the lspci output. I was able to create and > destroy VF's though the /sys interface with no further trouble. > > > I'll send the entire output of "lspci -vvv" in a moment - no need to > spam the list with that. > > > Can you tell me what cryptic acronyms I need to repair in coreboot so > those kernel options aren't necessary? > > > > Huge help, thanks again, > > - Kevin > > > On 05/07/2018 12:40 PM, Alexander Duyck wrote: >> On Sat, May 5, 2018 at 6:09 PM, Kevin Cody-Little <kcod...@gmail.com> wrote: >>> Folks, >>> >>> >>> I bought into parts for a new home firewall thinking it would provide an >>> IOMMU. As it turns out, that's a "cancelled feature" on AM1 systems, and >>> now I've got an ET in my hands that may as well be a PT. >> You can still allocate VFs assuming your platform supports SR-IOV, you >> just wouldn't be able to assign the VFs to a guest securely since you >> wouldn't have any memory isolation between the guests and your host >> system. SR-IOV itself doesn't have any dependency on the IOMMU, it is >> the VFIO driver that has requirements for that in order to assign it >> to a KVM guest. >> >>> I was wondering if it's possible to activate the virtual functions of >>> the card without one? Let's say if I don't care about passing the device >>> into a KVM guest, but only want to make a additional "ethFOO" devices >>> appear and assign them into LXC namespaces? >> If the SR-IOV isn't working at all then the issue is probably the fact >> that the BIOS hasn't assigned either busses or resources to the device >> for the VFs. One thing that would be useful would be a "lspci -vvv" >> dump for one of the ports in question in order to verify. I suspect >> you will need to use the kernel boot parameters "pci=assign-busses" >> and "pci=realloc". With those two parameters the kernel should >> allocate a set of busses for the VFs assuming you don't have support >> for ARI, and it should reallocate the resources to the device which >> should populate the SR-IOV BAR. >> >>> I could probably handle code changes for something like this, if someone >>> who's current on the codebase can help me work out a strategy and a >>> to-do list. >> The above suggestions should be all that is needed to get the SR-IOV >> functionality working on the host. >> >> Hope that helps. >> >> - Alex > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ E1000-devel mailing list E1000-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/e1000-devel To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
