Alex,
Okay, so it sounds like I need to cut into where coreboot detects what PCI devices are present, sense whether they need buses and resources allocated for SR-IOV, and then do so using whatever means coreboot is already providing. Is there a device-independent way to know whether and what resources/buses need to be allocated for SR-IOV for whatever gets detected, or am I going to be stuck with comparing vendor/device ID's to a table of known cards? Yes, the lspci -vvv was from after getting it working. If there's value in seeing the old state, I can reboot and send it to you easily enough. Thanks again, - Kevin On 05/09/2018 12:53 PM, Alexander Duyck wrote: > 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
