All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yinghai Lu <yinghai@kernel.org>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: Guo Chao <yan@linux.vnet.ibm.com>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>
Subject: Re: [PATCH] pci: Allow very large resource windows
Date: Thu, 3 Jul 2014 12:59:21 -0700	[thread overview]
Message-ID: <CAE9FiQWPGXMBYmpzyk8cicKZ1ELUZiARkZjr2vvgntmt3bt1jQ@mail.gmail.com> (raw)
In-Reply-To: <20140703131526.GG28852@google.com>

On Thu, Jul 3, 2014 at 6:15 AM, Bjorn Helgaas <bhelgaas@google.com> wrote:
>>
>> >> +     mem64_mask = b_res->flags & IORESOURCE_MEM_64;
>> >> +
>> >> +     /* kernel does not support 64bit res */
>> >> +     if (sizeof(resource_size_t) == 4)
>> >> +             mem64_mask &= ~IORESOURCE_MEM_64;
>
> I think you're fixing two things at once, and they should be split
> into two separate patches:
>
>   1) Change aligns[] size to increase support alignment from 8GB to 2^63
>
>      I'm not sure about going all the way to aligns[44].  That array
>      by itself puts 352 bytes in the stack frame (240 of which are
>      added by this patch), which seems excessive.  I suspect that
>      supporting BARs up to 64GB or 128GB would be enough for the
>      foreseeable future.

ok, let's use 128G this time.

>
>   2) Adding mem64_mask
>
>      I think the idea is that even if we have a 64-bit window, we
>      can't use anything above 4GB if we only have 32-bit resources.
>      That's true, but I don't think we can enforce that in
>      pbus_size_mem() because we're only figuring out how much space is
>      needed; we have no idea where that space will be allocated.

with current version of __pci_bus_size_bridges, we separate pref_mem64 with
pref_mem32 to calling pbus_size_mem.

so if we have pref 64bit window, we will only size pref 64 bit
children under it.
and will only assign pref 64bit mem64 to them late.

If the bridge does not support 64bit pref windows, and child support
64bit pref mmio, then bridge will try to use pref 32 window, in that
case, .... could have
size overflow as you state follow.

>
> And I think there are more problems:
>
>   - I don't think we handle overflow of "size" correctly.  Assume that
>     we have BARs of 2GB, 2GB, and 8GB.  If we have 32-bit resources,
>     when we add those up, it will overflow and we'll mistakenly think
>     we only need 8MB.

in this case we should check the overflow.

>
>   - We shouldn't set "r->flags = 0".  The warning says we're disabling
>     the BAR, but this *doesn't* disable the BAR, and in fact, there is
>     no way to disable a single BAR.  What we can do is turn off
>     PCI_COMMAND_MEMORY to disable all the memory BARs for the device.
>     And to do that, we need to keep IORESOURCE_MEM in r->flags so
>     pci_enable_resources() can tell that this is a memory BAR.

when we try to size it,  means that bar is not assigned. with r->flags
= 0, means
we will ignore it all the way.

Thanks

Yinghai

  reply	other threads:[~2014-07-03 19:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-11  6:01 [PATCH] pci: Allow very large resource windows Guo Chao
2014-06-11 17:23 ` Yinghai Lu
2014-06-12 11:32   ` Guo Chao
2014-07-02 21:07   ` Bjorn Helgaas
2014-07-02 22:54     ` Yinghai Lu
2014-07-03 13:15       ` Bjorn Helgaas
2014-07-03 19:59         ` Yinghai Lu [this message]
2014-07-03 22:11           ` Bjorn Helgaas
2014-07-11  1:12             ` Yinghai Lu
2014-07-11 18:00               ` Bjorn Helgaas
2014-07-11 18:09                 ` Yinghai Lu
2014-07-11 18:21                   ` Linus Torvalds
2014-07-11 18:40                     ` Bjorn Helgaas
2014-07-12  1:22                       ` Yinghai Lu
2014-09-04  4:20                         ` Bjorn Helgaas
  -- strict thread matches above, loose matches on Subject: below --
2014-05-19 13:03 Alan
2014-05-19 20:28 ` Bjorn Helgaas
2014-05-23 17:51   ` Kevin Hilman
2014-05-23 17:51     ` Kevin Hilman
2014-05-23 18:41     ` Bjorn Helgaas
2014-05-23 18:41       ` Bjorn Helgaas
2014-04-28 20:23 Alan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAE9FiQWPGXMBYmpzyk8cicKZ1ELUZiARkZjr2vvgntmt3bt1jQ@mail.gmail.com \
    --to=yinghai@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=yan@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.