Kevin, What you need to do to take care of the busses and resources is walk the PCIe configuration space to see if there is a SR-IOV configuration space present. If there is then it should contain the data on offset and stride it uses to allocate VFs. From that you can derive the buses. As far as the resources you would need to walk through the BAR registers in the SR-IOV configuration space and assign them memory addresses to work with. Once those two bits are taken care of then it should all work.
If you wanted to take it one step further you could look to see if ARI is supported before taking care of the SR-IOV configuration bits. The reason I mention that is that if ARI is enabled it will impact the stride and/or offset of the VFs since it might allow them to all occupy one bus instead of having to access multiple busses/devices. Thanks. - Alex On Wed, May 9, 2018 at 10:13 AM, Kevin Cody-Little <kcod...@gmail.com> wrote: > 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
