From: Bjorn Helgaas <bhelgaas@google.com>
To: linux-pci@vger.kernel.org, Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: David Airlie <airlied@linux.ie>, Yinghai Lu <yinghai@kernel.org>,
Guo Chao <yan@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH v7 14/15] PCI: Enforce bus address limits in resource allocation
Date: Mon, 06 Jan 2014 17:56:51 -0700 [thread overview]
Message-ID: <20140107005651.10786.28216.stgit@bhelgaas-glaptop.roam.corp.google.com> (raw)
In-Reply-To: <20140107005003.10786.85164.stgit@bhelgaas-glaptop.roam.corp.google.com>
From: Yinghai Lu <yinghai@kernel.org>
When allocating space for 32-bit BARs, we previously limited RESOURCE
addresses so they would fit in 32 bits. However, the BUS address need not
be the same as the resource address, and it's the bus address that must fit
in the 32-bit BAR.
This patch adds:
- pci_clip_resource_to_region(), which clips a resource so it contains
only the range that maps to the specified bus address region, e.g., to
clip a resource to 32-bit bus addresses, and
- pci_bus_alloc_from_region(), which allocates space for a resource from
the specified bus address region,
and changes pci_bus_alloc_resource() to allocate space for 64-bit BARs from
the entire bus address region, and space for 32-bit BARs from only the bus
address region below 4GB.
If we had this window:
pci_root HWP0002:0a: host bridge window [mem 0xf0180000000-0xf01fedfffff] (bus address [0x80000000-0xfedfffff])
we previously could not put a 32-bit BAR there, because the CPU addresses
don't fit in 32 bits. This patch fixes this, so we can use this space for
32-bit BARs.
It's also possible (though unlikely) to have resources with 32-bit CPU
addresses but bus addresses above 4GB. In this case the previous code
would allocate space that a 32-bit BAR could not map.
Remove PCIBIOS_MAX_MEM_32, which is no longer used.
[bhelgaas: reworked starting from http://lkml.kernel.org/r/1386658484-15774-3-git-send-email-yinghai@kernel.org]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
arch/x86/include/asm/pci.h | 1
drivers/pci/bus.c | 107 ++++++++++++++++++++++++++++++++------------
include/linux/pci.h | 4 --
3 files changed, 79 insertions(+), 33 deletions(-)
diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 947b5c417e83..122c299e90c8 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -125,7 +125,6 @@ int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
/* generic pci stuff */
#include <asm-generic/pci.h>
-#define PCIBIOS_MAX_MEM_32 0xffffffff
#ifdef CONFIG_NUMA
/* Returns the node based on pci bus */
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 6f2f47a7b6c6..58beaaba50ee 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -98,41 +98,50 @@ void pci_bus_remove_resources(struct pci_bus *bus)
}
}
-/**
- * pci_bus_alloc_resource - allocate a resource from a parent bus
- * @bus: PCI bus
- * @res: resource to allocate
- * @size: size of resource to allocate
- * @align: alignment of resource to allocate
- * @min: minimum /proc/iomem address to allocate
- * @type_mask: IORESOURCE_* type flags
- * @alignf: resource alignment function
- * @alignf_data: data argument for resource alignment function
- *
- * Given the PCI bus a device resides on, the size, minimum address,
- * alignment and type, try to find an acceptable resource allocation
- * for a specific device resource.
+static struct pci_bus_region pci_32_bit = {0, 0xffffffffULL};
+static struct pci_bus_region pci_64_bit = {0,
+ (resource_size_t) 0xffffffffffffffffULL};
+
+/*
+ * @res contains CPU addresses. Clip it so the corresponding bus addresses
+ * on @bus are entirely within @region. This is used to control the bus
+ * addresses of resources we allocate, e.g., we may need a resource that
+ * can be mapped by a 32-bit BAR.
*/
-int
-pci_bus_alloc_resource(struct pci_bus *bus, struct resource *res,
+static void pci_clip_resource_to_region(struct pci_bus *bus,
+ struct resource *res,
+ struct pci_bus_region *region)
+{
+ struct pci_bus_region r;
+
+ pcibios_resource_to_bus(bus, &r, res);
+ if (r.start < region->start)
+ r.start = region->start;
+ if (r.end > region->end)
+ r.end = region->end;
+
+ if (r.end < r.start)
+ res->end = res->start - 1;
+ else
+ pcibios_bus_to_resource(bus, res, &r);
+}
+
+static int pci_bus_alloc_from_region(struct pci_bus *bus, struct resource *res,
resource_size_t size, resource_size_t align,
resource_size_t min, unsigned int type_mask,
resource_size_t (*alignf)(void *,
const struct resource *,
resource_size_t,
resource_size_t),
- void *alignf_data)
+ void *alignf_data,
+ struct pci_bus_region *region)
{
- int i, ret = -ENOMEM;
- struct resource *r;
- resource_size_t max = -1;
+ int i, ret;
+ struct resource *r, avail;
+ resource_size_t max;
type_mask |= IORESOURCE_IO | IORESOURCE_MEM;
- /* don't allocate too high if the pref mem doesn't support 64bit*/
- if (!(res->flags & IORESOURCE_MEM_64))
- max = PCIBIOS_MAX_MEM_32;
-
pci_bus_for_each_resource(bus, r, i) {
if (!r)
continue;
@@ -147,22 +156,64 @@ pci_bus_alloc_resource(struct pci_bus *bus, struct resource *res,
!(res->flags & IORESOURCE_PREFETCH))
continue;
+ avail = *r;
+ pci_clip_resource_to_region(bus, &avail, region);
+ if (!resource_size(&avail))
+ continue;
+
/*
* "min" is typically PCIBIOS_MIN_IO or PCIBIOS_MIN_MEM to
* protect badly documented motherboard resources, but if
* this is an already-configured bridge window, its start
* overrides "min".
*/
- if (r->start)
- min = r->start;
+ if (avail.start)
+ min = avail.start;
+
+ max = avail.end;
/* Ok, try it out.. */
ret = allocate_resource(r, res, size, min, max,
align, alignf, alignf_data);
if (ret == 0)
- break;
+ return 0;
}
- return ret;
+ return -ENOMEM;
+}
+
+/**
+ * pci_bus_alloc_resource - allocate a resource from a parent bus
+ * @bus: PCI bus
+ * @res: resource to allocate
+ * @size: size of resource to allocate
+ * @align: alignment of resource to allocate
+ * @min: minimum /proc/iomem address to allocate
+ * @type_mask: IORESOURCE_* type flags
+ * @alignf: resource alignment function
+ * @alignf_data: data argument for resource alignment function
+ *
+ * Given the PCI bus a device resides on, the size, minimum address,
+ * alignment and type, try to find an acceptable resource allocation
+ * for a specific device resource.
+ */
+int
+pci_bus_alloc_resource(struct pci_bus *bus, struct resource *res,
+ resource_size_t size, resource_size_t align,
+ resource_size_t min, unsigned int type_mask,
+ resource_size_t (*alignf)(void *,
+ const struct resource *,
+ resource_size_t,
+ resource_size_t),
+ void *alignf_data)
+{
+ if (res->flags & IORESOURCE_MEM_64)
+ return pci_bus_alloc_from_region(bus, res, size, align, min,
+ type_mask, alignf, alignf_data,
+ &pci_64_bit);
+
+ return pci_bus_alloc_from_region(bus, res, size, align, min,
+ type_mask, alignf, alignf_data,
+ &pci_32_bit);
}
void __weak pcibios_resource_survey_bus(struct pci_bus *bus) { }
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 966b286b5d53..095eb44fcbb6 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1493,10 +1493,6 @@ static inline struct pci_dev *pci_dev_get(struct pci_dev *dev)
#include <asm/pci.h>
-#ifndef PCIBIOS_MAX_MEM_32
-#define PCIBIOS_MAX_MEM_32 (-1)
-#endif
-
/* these helpers provide future and backwards compatibility
* for accessing popular PCI BAR info */
#define pci_resource_start(dev, bar) ((dev)->resource[(bar)].start)
next prev parent reply other threads:[~2014-01-07 0:56 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-07 0:55 [PATCH v7 00/15] PCI: Allocate 64-bit BARs above 4G when possible Bjorn Helgaas
2014-01-07 0:55 ` [PATCH v7 01/15] PCI: Change pci_bus_region addresses to dma_addr_t Bjorn Helgaas
2014-01-07 0:55 ` [PATCH v7 02/15] PCI: Convert pcibios_resource_to_bus() to take a pci_bus, not a pci_dev Bjorn Helgaas
2014-01-07 0:55 ` [PATCH v7 03/15] PCI: Add pci_bus_address() to get bus address of a BAR Bjorn Helgaas
2014-01-07 0:55 ` [PATCH v7 04/15] agp: Support 64-bit APBASE Bjorn Helgaas
2014-01-07 0:55 ` [PATCH v7 05/15] agp: Use pci_resource_start() to get CPU physical address for BAR Bjorn Helgaas
2014-01-07 0:55 ` [PATCH v7 06/15] drm/i915: Rename gtt_bus_addr to gtt_phys_addr Bjorn Helgaas
2014-01-07 0:56 ` [PATCH v7 07/15] agp/intel: " Bjorn Helgaas
2014-01-07 0:56 ` [PATCH v7 08/15] agp/intel: Support 64-bit GMADR Bjorn Helgaas
2014-01-07 0:56 ` [PATCH v7 09/15] agp/intel: Use pci_bus_address() to get MMADR bus address Bjorn Helgaas
2014-01-07 0:56 ` [PATCH v7 10/15] agp/intel: Use pci_bus_address() to get GTTADR " Bjorn Helgaas
2014-01-07 0:56 ` [PATCH v7 11/15] agp/intel: Use CPU physical address, not bus address, for ioremap() Bjorn Helgaas
2014-01-07 0:56 ` [PATCH v7 12/15] agp/ati: Use PCI_COMMAND instead of hard-coded 4 Bjorn Helgaas
2014-01-07 0:56 ` [PATCH v7 13/15] PCI: Split out bridge window override of minimum allocation address Bjorn Helgaas
2014-01-07 0:56 ` Bjorn Helgaas [this message]
2014-01-07 0:56 ` [PATCH v7 15/15] PCI: Allocate 64-bit BARs above 4G when possible Bjorn Helgaas
2014-01-07 10:46 ` [PATCH v7 00/15] " Daniel Vetter
2014-01-07 18:46 ` Bjorn Helgaas
2014-01-10 21:34 ` Bjorn Helgaas
2014-01-15 5:14 ` Dave Airlie
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=20140107005651.10786.28216.stgit@bhelgaas-glaptop.roam.corp.google.com \
--to=bhelgaas@google.com \
--cc=airlied@linux.ie \
--cc=daniel.vetter@ffwll.ch \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=yan@linux.vnet.ibm.com \
--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
all inboxes | Powered by JetHome®