From: Gavin Shan <gwshan@linux.vnet.ibm.com>
To: yinghai@kernel.org
Cc: bhelgaas@google.com, benh@kernel.crashing.org, ruscur@russell.cc,
linux-pci@vger.kernel.org
Subject: [Discussion] PCI Resource Resizing & Assignment
Date: Tue, 20 Sep 2016 12:33:28 +1000 [thread overview]
Message-ID: <20160920023328.GA8527@gwshan> (raw)
Hi Yinghai,
The purpose of this is going to have some discussion on current PCI resource
resizing and assignment implementation, mainly related to __pci_bus_size_bridges()
and pbus_size_mem().
In current implementation, all 64-bits and prefetchable BARs are going to be covered
by 64-bits and prefetchable bridge windows, and all other types of BARs are covered
by 32-bits bridge windows. It means 64-bits and non-prefetchable BARs are assigned
from 32-bits bridge windows which is usually limited and 2GB on our PowerNV platform.
It seems the attribute ("prefetchable") plays important role in the design so that
the final resource layout is compatible with: non-prefetchable BARs cannot be covered
by prefetchable bridge windows. It seems that's not true any more in PCI express domain,
meaning non-prefetchable BARs can live under prefetchable bridge windows. If so, I
think the "prefetchable" attribute isn't important and shouldn't affect the implementation
so much as we had. PCI/PCIx domain still have the problem: non-prefetchable BARs cannot
live behind a prefetchable bridge window. Apart from PCI/PCIx, we probably need enhance
current implementation for PCIe domain: 64-bits BARs are covered by 64-bits bridge windows
and 32-bits BARs are covered by 32-bits bridge windows, meaning the attribute "prefetchable"
won't have effect during resizing/assignment in PCIe domain. We will benefit from the
enhancement: (A) 64-bits non-prefetchable BARs will be covered by 64-bits prefetchable
bridge windows instead of 32-bits bridge windows, avoid 32-bits resource to be exhausted
quickly. (B) VFs whose BARs isn't 64-bits and prefetchable cannot be enabled on PowerNV
platform. It's not a issue with this enhancement.
The situation becomes complicated when we have combination of PCIe and PCI/PCIx domains.
We still need follow the rule in this scenario: non-prefetchable BARs cannot be covered
by prefetchable bridge windows. It might be more complicated with PCI hotplug is under
consideration. However, the platform (e.g. PowerNV) could have clear idea if PCI/PCIx
is going to be supported on particular PHB. I think the above enhancement can be applied
if PCI/PCIx won't be supported on particular PHB.
Thanks,
Gavin
next reply other threads:[~2016-09-20 2:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-20 2:33 Gavin Shan [this message]
2016-09-20 21:24 ` [Discussion] PCI Resource Resizing & Assignment Benjamin Herrenschmidt
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=20160920023328.GA8527@gwshan \
--to=gwshan@linux.vnet.ibm.com \
--cc=benh@kernel.crashing.org \
--cc=bhelgaas@google.com \
--cc=linux-pci@vger.kernel.org \
--cc=ruscur@russell.cc \
--cc=yinghai@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).