On 10/06/2011 05:03 PM, Nishanth Aravamudan 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). > > 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. > > This was tested to not result in BAR collisions against > 3.1.0-rc9-00012-g6367f17. > > Signed-off-by: Nishanth Aravamudan <nacc@xxxxxxxxxx> I don't have any strenuous objection to this patch ... but it seems like an easier approach would be to have a sriov on/off switch which would a) be configurable by distributions, b) aid in debugging I'd rather see that approach than this one. Just my two cents, P. -- 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
