On Wednesday, September 08, 2010 03:44:38 pm Ram Pai wrote: > On Wed, Sep 08, 2010 at 02:35:13PM -0600, Bjorn Helgaas wrote: > > What specific problem are you solving? Does this patch enable > > us to assign resources to a device that previously had none? > > A concrete example might help. > > On machines with BIOS/uEFI that is unaware of SRIOV BARs, the BIOS/uEFI > fails to allocate memory resources to the SRIOV BARs of PCIe functions. > On such machines PCI-e Virtual functions cannot be enabled. I think you mean that an upstream bridge window might not be big enough to assign SR-IOV BARs, so we might have to reassign peers of the bridge so we can expand the window. But a concrete example would make this clear. > Also on machines where BIOS/uEFI allocations conflict, the corresponding > devices are disabled. What does it mean for BIOS allocations to conflict? Two BARs that claim the same space? Is that a BIOS defect? > This patch provides the user the ability to explicitly tell the kernel > to try and allocate resources to such devices or resolve any conflicts. > > By default the kernel disables all devices that have conflicting or no > allocations. > > > Signed-off-by: Ram Pai <linuxram@xxxxxxxxxx> > > > > > > diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt > > > index f084af0..eec068f 100644 > > > --- a/Documentation/kernel-parameters.txt > > > +++ b/Documentation/kernel-parameters.txt > > > @@ -1961,6 +1961,21 @@ and is between 256 and 4096 characters. It is defined in the file > > > PAGE_SIZE is used as alignment. > > > PCI-PCI bridge can be specified, if resource > > > windows need to be expanded. > > > + override=[off, conflict, always, <device>] > > > + off : Do not override BIOS/firmware allocations. This is the > > > + default > > > + conflict : override BIOS/firmware allocations if conflicting > > > + or not allocated. > > > + always : override all BIOS/firmware allocations > > > + <device>: Format [<domain>:]<bus>:<slot>.<func>[; ...] > > > + override BIOS/firmware allocations of specified > > > + devices > > > + > > > + clear=<device> > > > + <device>: Format [<domain>:]<bus>:<slot>.<func>[; ...] > > > + release BIOS/firmware allocations of specified > > > + devices. By default no allocations are cleared. > > > > I object in principle to new kernel parameters that users might need > > to use just to get their box to work. How would a user know that he > > might need this option? Isn't it possible for the kernel to figure > > that out automatically? > > The user can use these options only if he/she realizes that some devices are > disabled. These options are not needed in the normal case which is about 95% of > the time. But I need these parameter to get my box working with SRIOV adapters. > And I am sure they are needed for many other boxes that face similar issue. I don't think this is a very convincing argument. As a user, I don't want to have to "realize some devices are disabled" and then grope around for an option to fix things up. As a vendor, I don't want to have to mention stuff like this in release notes for machines that might need it. >From your other response: > Well Yanghai's patch, git commit 977d17bb1749517b353874ccdc9b85abc7a58c2a, > tried to automate the process. But it was error prone and caused regression. Is it actually impossible to do it automatically, or did we just not try hard enough? Bjorn -- 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
