On 06.10.2011 [17:01:31 -0600], Bjorn Helgaas wrote: > On Thu, Oct 6, 2011 at 3:03 PM, Nishanth Aravamudan <nacc@xxxxxxxxxx> wrote: > > We have observed the following on Power systems with SR-IOV capable > > adapters: > > > > lpfc 0002:01:00.0: device not available because of BAR 7 [0x000000-0x00ffff] collisions > > > > The issue is that on Power systems, PCI BARs cannot be remapped and VF > > BARs might have values that collide. As far as I can tell, the current > > SR-IOV code cannot be supported on Power and so it seems like we could > > provide a hook for an architecture that might set CONFIG_PCI_IOV to > > disable SR-IOV support (potentially at run-time). > > Are you saying that Power is intrinsically unable to support SR-IOV? > Or is it merely that we can't use SR-IOV on this particular > machine/configuration because the BAR assignments are fixed and there > isn't enough space for the VF BARs? > > I would expect the latter, and therefore it seems wrong to disable it > across the board. Perhaps on another machine with different PCI > resource assignments, there *would* be space for the VF BARs and > SR-IOV could be used. That's a fair point -- we depend on system firmware to allocate our resources for us (so to be clear BAR assignments *are* fixed on pseries (running on PowerVM) for that reason) and in theory that could be setup correctly. > > I defined a weak version of this function that returns true if > > CONFIG_PCI_IOV is set (which I think should reflect the current setup > > that CONFIG_PCI_IOV represents an unconditional support of SR-IOV) and > > false otherwise. The only architecture that implements the hook is > > powerpc, which uses a machine callback to decide if a platform supports > > SR-IOV or not. I only defined one such callback, for the pseries > > platform, and return false unconditionally there. > > I think this approach is a band-aid that happens to cover up the > problem. I'd rather fix the PF enable path so it doesn't depend on VF > BAR allocation. That seems like a much cleaner approach to me. I > think your pci_select_bars() patch is acceptable for now, even though > I would still like to see us move all the VF BAR stuff out of the > pci_dev and into the pci_sriov. I would agree with you :) I hadn't heard from Ram in a bit and wanted to keep the dialogue going. I do believe he is working on it, but I think there have been some holidays lately in China where he is at. > It's true that this patch might be "safer" in the sense that it barely > touches the generic code, but I'd prefer to take the risk and make the > generic code better for everybody. I'm fine with that if you are. Thanks, Nish -- Nishanth Aravamudan <nacc@xxxxxxxxxx> IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
