On Thu, 2011-10-06 at 17:43 -0400, Prarit Bhargava wrote: > > 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, Those are orthogonal. On Power, a kernel can support several platforms which will or not support SR-IOV depending on what environment they are booted with, so we want something under platform control. Cheers, Ben. -- 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
