linux-kernel - Re: [PATCH 9/9] PCI: only enable pci realloc when SRIOV bar is not assigned

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAE9FiQX5Ln9YM6gh-cm8_OiJpMHgD8dpYo1_4rVm35K4F_gP6Q@mail.gmail.com>
Date:	Fri, 10 Feb 2012 13:23:23 -0800
From:	Yinghai Lu <yinghai@...nel.org>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	Ram Pai <linuxram@...ibm.com>,
	Dominik Brodowski <linux@...inikbrodowski.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 9/9] PCI: only enable pci realloc when SRIOV bar is not assigned

On Fri, Feb 10, 2012 at 1:00 PM, Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
> On Sat,  4 Feb 2012 22:55:08 -0800
> Yinghai Lu <yinghai@...nel.org> wrote:
>
>> If bios does not assign those BAR or wrong address, then kernel will
>> try to do pci realloc.
>>
>> in that case, user still can use pci=realloc=off to override it.
>>
>> Signed-off-by: Yinghai Lu <yinghai@...nel.org>
>> ---
>>  drivers/pci/setup-bus.c |   28 ++++++++++++++++++++++++++++
>>  1 files changed, 28 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
>> index 9526038..520f256 100644
>> --- a/drivers/pci/setup-bus.c
>> +++ b/drivers/pci/setup-bus.c
>> @@ -1293,6 +1293,31 @@ static bool __init pci_realloc_enabled(void)
>>       return pci_realloc_enable >= enable_yes_user;
>>  }
>>
>> +static void __init pci_realloc_detect(void)
>> +{
>> +     struct pci_dev *dev = NULL;
>> +
>> +     if (pci_realloc_enable != enable_not_set)
>> +             return;
>> +
>> +#ifdef CONFIG_PCI_IOV
>> +     for_each_pci_dev(dev) {
>> +             int i;
>> +
>> +             for (i = PCI_IOV_RESOURCES; i <= PCI_IOV_RESOURCE_END; i++) {
>> +                     struct resource *r = &dev->resource[i];
>> +
>> +                     /* Not assigned, or rejected by kernel */
>> +                     if (r->flags && !r->start) {
>> +                             pci_realloc_enable = enable_yes_detected;
>> +
>> +                             return;
>> +                     }
>> +             }
>> +     }
>> +#endif
>> +}
>> +
>>  /*
>>   * first try will not touch pci bridge res
>>   * second  and later try will clear small leaf bridge res
>> @@ -1314,6 +1339,7 @@ pci_assign_unassigned_resources(void)
>>       int pci_try_num = 1;
>>
>>       /* don't realloc if asked to do so */
>> +     pci_realloc_detect();
>>       if (pci_realloc_enabled()) {
>>               int max_depth = pci_get_max_depth();
>>
>> @@ -1348,6 +1374,8 @@ again:
>>       if (tried_times >= pci_try_num) {
>>               if (pci_realloc_enable == enable_not_set)
>>                       printk(KERN_INFO "Some pci devices resources are not assigned, please try to boot with pci=realloc\n");
>> +             else if (pci_realloc_enable == enable_yes_detected)
>> +                     printk(KERN_INFO "Automatically enabled pci realloc, if you have problem, please try to boot with pci=realloc=off\n");
>>
>>               free_list(&fail_head);
>>               goto enable_and_dump;
>
> Not sure I like this one either.  Distros will want to enable IOV by
> default, but in most configs users still won't use it, and many BIOSes
> won't bother to allocate IOV space.  So defaulting to trying to do so
> will likely cause a lot of unnecessary re-allocation.
>
> So distro guidance would be appreciated here for the default behavior.

Or do you prefer to:

if all SRIOV bar are not assigned, We will not enable SRIOV feature even?

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/