This is a v4 of Gavin's series for handling VF BAR updates. The
important piece is the first patch ("PCI: Do any VF BAR updates before
enabling the BARs"). That makes sure that if we update VF BARs, we do
it before enabling the VFs, and that is unchanged from v3.
The second patch in Gavin's series ("PCI: Disable VF's memory space on
updating IOV BAR in pci_update_resource()") temporarily disabled VF
memory space during an update. Since the first patch does the update
before enabling VFs, this case shouldn't happen in practice.
But even if we want to update a VF BAR while VF memory space is
enabled, I think temporarily disabling it is wrong. So I replaced
the second patch with a few patches that make that such an update
fail.
Please comment. These are on my pci/virtualization branch.
Changelog
=========
v4:
* Don't disable VF's memory space when IOV BARs are updated; fail the
update instead.
* Split IOV BAR updates from standard BAR updates so IOV updates can go
in pci/iov.c.
* Remove pci_resource_bar() and pci_iov_resource_bar() (the relevant
code is simpler when inlined into the callers).
* Cleanup IORESOURCE_ROM_ENABLE usage.
* Add comments about why ROMs are updated differently.
v3:
* Disable VF's memory space when IOV BARs are updated in
pcibios_sriov_enable().
v2:
* Added one patch calling pcibios_sriov_enable() before the VF
and VF BARs are enabled.
---
Bjorn Helgaas (6):
PCI: Ignore BAR updates on virtual functions
PCI: Separate VF BAR updates from standard BAR updates
PCI: Don't update VF BARs while VF memory space is enabled
PCI: Remove pci_resource_bar() and pci_iov_resource_bar()
PCI: Decouple IORESOURCE_ROM_ENABLE and PCI_ROM_ADDRESS_ENABLE
PCI: Add comments about ROM BAR updating
Gavin Shan (1):
PCI: Do any VF BAR updates before enabling the BARs
drivers/pci/iov.c | 69 +++++++++++++++++++++++++++++++++++++----------
drivers/pci/pci.c | 34 -----------------------
drivers/pci/pci.h | 7 +----
drivers/pci/probe.c | 3 +-
drivers/pci/rom.c | 5 +++
drivers/pci/setup-res.c | 37 ++++++++++++++++++-------
6 files changed, 88 insertions(+), 67 deletions(-)
From: Gavin Shan <redacted>
Previously we enabled VFs and enable their memory space before calling
pcibios_sriov_enable(). But pcibios_sriov_enable() may update the VF BARs:
for example, on PPC PowerNV we may change them to manage the association of
VFs to PEs.
Because 64-bit BARs cannot be updated atomically, it's unsafe to update
them while they're enabled. The half-updated state may conflict with other
devices in the system.
Call pcibios_sriov_enable() before enabling the VFs so any BAR updates
happen while the VF BARs are disabled.
[bhelgaas: changelog]
Tested-by: Carol Soto <redacted>
Signed-off-by: Gavin Shan <redacted>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/pci/iov.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
VF BARs are read-only zero, so updating VF BARs will not have any effect.
See the SR-IOV spec r1.1, sec 3.4.1.11.
We already ignore these updates because of 70675e0b6a1a ("PCI: Don't try to
restore VF BARs"); this merely restructures it slightly to make it easier
to split updates for standard and SR-IOV BARs.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Wei Yang <redacted>
---
drivers/pci/pci.c | 4 ----
drivers/pci/setup-res.c | 5 ++---
2 files changed, 2 insertions(+), 7 deletions(-)
Previously pci_update_resource() used the same code path for updating
standard BARs and VF BARs in SR-IOV capabilities.
Split the VF BAR update into a new pci_iov_update_resource() internal
interface, which makes it simpler to compute the BAR address (we can get
rid of pci_resource_bar() and pci_iov_resource_bar()).
This patch:
- Renames pci_update_resource() to pci_std_update_resource(),
- Adds pci_iov_update_resource(),
- Makes pci_update_resource() a wrapper that calls the appropriate one,
No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/pci/iov.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++
drivers/pci/pci.h | 1 +
drivers/pci/setup-res.c | 13 +++++++++++-
3 files changed, 61 insertions(+), 2 deletions(-)
@@ -571,6 +571,55 @@ int pci_iov_resource_bar(struct pci_dev *dev, int resno)4*(resno-PCI_IOV_RESOURCES);}+/**+*pci_iov_update_resource-updateaVFBAR+*@dev:thePCIdevice+*@resno:theresourcenumber+*+*UpdateaVFBARintheSR-IOVcapabilityofaPF.+*/+voidpci_iov_update_resource(structpci_dev*dev,intresno)+{+structpci_sriov*iov=dev->is_physfn?dev->sriov:NULL;+structresource*res=dev->resource+resno;+intvf_bar=resno-PCI_IOV_RESOURCES;+structpci_bus_regionregion;+u32new;+intreg;++/*+*Thegenericpci_restore_bars()pathcallsthisforalldevices,+*includingVFsandnon-SR-IOVdevices.IfthisisnotaPF,we+*havenothingtodo.+*/+if(!iov)+return;++/*+*IgnoreunimplementedBARs,unusedresourceslotsfor64-bit+*BARs,andnon-movableresources,e.g.,thosedescribedvia+*EnhancedAllocation.+*/+if(!res->flags)+return;++if(res->flags&IORESOURCE_UNSET)+return;++if(res->flags&IORESOURCE_PCI_FIXED)+return;++pcibios_resource_to_bus(dev->bus,®ion,res);+new=region.start;++reg=iov->pos+PCI_SRIOV_BAR+4*vf_bar;+pci_write_config_dword(dev,reg,new);+if(res->flags&IORESOURCE_MEM_64){+new=region.start>>16>>16;+pci_write_config_dword(dev,reg+4,new);+}+}+resource_size_t__weakpcibios_iov_resource_alignment(structpci_dev*dev,intresno){
If we update a VF BAR while it's enabled, there are two potential problems:
1) Any driver that's using the VF has a cached BAR value that is stale
after the update, and
2) We can't update 64-bit BARs atomically, so the intermediate state
(new lower dword with old upper dword) may conflict with another
device, and an access by a driver unrelated to the VF may cause a bus
error.
Warn about attempts to update VF BARs while they are enabled. This is a
programming error, so use dev_WARN() to get a backtrace.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/pci/iov.c | 8 ++++++++
1 file changed, 8 insertions(+)
pci_std_update_resource() only deals with standard BARs, so we don't have
to worry about the complications of VF BARs in an SR-IOV capability.
Compute the BAR address inline and remove pci_resource_bar(). That makes
pci_iov_resource_bar() unused, so remove that as well.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/pci/iov.c | 18 ------------------
drivers/pci/pci.c | 30 ------------------------------
drivers/pci/pci.h | 6 ------
drivers/pci/setup-res.c | 13 +++++++------
4 files changed, 7 insertions(+), 60 deletions(-)
Remove the assumption that IORESOURCE_ROM_ENABLE == PCI_ROM_ADDRESS_ENABLE.
PCI_ROM_ADDRESS_ENABLE is the ROM enable bit defined by the PCI spec, so if
we're reading or writing a BAR register value, that's what we should use.
IORESOURCE_ROM_ENABLE is a corresponding bit in struct resource flags.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/pci/probe.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
pci_update_resource() updates a hardware BAR so its address matches the
kernel's struct resource UNLESS it's a disabled ROM BAR. We only update
those when we enable the ROM.
It's not obvious from the code why ROM BARs should be handled specially.
Apparently there are Matrox devices with defective ROM BARs that read as
zero when disabled. That means that if pci_enable_rom() reads the disabled
BAR, sets PCI_ROM_ADDRESS_ENABLE (without re-inserting the address), and
writes it back, it would enable the ROM at address zero.
Add comments and references to explain why we can't make the code look more
rational.
The code changes are from 755528c860b0 ("Ignore disabled ROM resources at
setup") and 8085ce084c0f ("[PATCH] Fix PCI ROM mapping").
Link: https://lkml.org/lkml/2005/8/30/138
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
---
drivers/pci/rom.c | 5 +++++
drivers/pci/setup-res.c | 6 ++++++
2 files changed, 11 insertions(+)
On Mon, Nov 28, 2016 at 10:14:29PM -0600, Bjorn Helgaas wrote:
VF BARs are read-only zero, so updating VF BARs will not have any effect.
See the SR-IOV spec r1.1, sec 3.4.1.11.
We already ignore these updates because of 70675e0b6a1a ("PCI: Don't try to
restore VF BARs"); this merely restructures it slightly to make it easier
to split updates for standard and SR-IOV BARs.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Wei Yang <redacted>
{
int i;
- /* Per SR-IOV spec 3.4.1.11, VF BARs are RO zero */
- if (dev->is_virtfn)
- return;
-
for (i = 0; i < PCI_BRIDGE_RESOURCES; i++)
pci_update_resource(dev, i);
}
On Mon, Nov 28, 2016 at 10:15:06PM -0600, Bjorn Helgaas wrote:
Previously pci_update_resource() used the same code path for updating
standard BARs and VF BARs in SR-IOV capabilities.
Split the VF BAR update into a new pci_iov_update_resource() internal
interface, which makes it simpler to compute the BAR address (we can get
rid of pci_resource_bar() and pci_iov_resource_bar()).
This patch:
- Renames pci_update_resource() to pci_std_update_resource(),
- Adds pci_iov_update_resource(),
- Makes pci_update_resource() a wrapper that calls the appropriate one,
No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
With below minor comments fixed:
Reviewed-by: Gavin Shan <redacted>
@@ -571,6 +571,55 @@ int pci_iov_resource_bar(struct pci_dev *dev, int resno)
4 * (resno - PCI_IOV_RESOURCES);
}
+/**
+ * pci_iov_update_resource - update a VF BAR
+ * @dev: the PCI device
+ * @resno: the resource number
+ *
+ * Update a VF BAR in the SR-IOV capability of a PF.
+ */
+void pci_iov_update_resource(struct pci_dev *dev, int resno)
+{
+ struct pci_sriov *iov = dev->is_physfn ? dev->sriov : NULL;
+ struct resource *res = dev->resource + resno;
+ int vf_bar = resno - PCI_IOV_RESOURCES;
+ struct pci_bus_region region;
+ u32 new;
+ int reg;
+
+ /*
+ * The generic pci_restore_bars() path calls this for all devices,
+ * including VFs and non-SR-IOV devices. If this is not a PF, we
+ * have nothing to do.
+ */
+ if (!iov)
+ return;
+
+ /*
+ * Ignore unimplemented BARs, unused resource slots for 64-bit
+ * BARs, and non-movable resources, e.g., those described via
+ * Enhanced Allocation.
+ */
+ if (!res->flags)
+ return;
+
+ if (res->flags & IORESOURCE_UNSET)
+ return;
+
+ if (res->flags & IORESOURCE_PCI_FIXED)
+ return;
+
+ pcibios_resource_to_bus(dev->bus, ®ion, res);
+ new = region.start;
+
The bits indicating the BAR's property (e.g. memory, IO etc) are missed in @new.
The last BAR is missed:
else if (resno >= PCI_IOV_RESOURCES && resno <= PCI_IOV_RESOURCE_END)
+ pci_iov_update_resource(dev, resno);
+#endif
+}
+
int pci_claim_resource(struct pci_dev *dev, int resource)
{
struct resource *res = &dev->resource[resource];
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 28, 2016 at 10:15:21PM -0600, Bjorn Helgaas wrote:
If we update a VF BAR while it's enabled, there are two potential problems:
1) Any driver that's using the VF has a cached BAR value that is stale
after the update, and
2) We can't update 64-bit BARs atomically, so the intermediate state
(new lower dword with old upper dword) may conflict with another
device, and an access by a driver unrelated to the VF may cause a bus
error.
Warn about attempts to update VF BARs while they are enabled. This is a
programming error, so use dev_WARN() to get a backtrace.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
@@ -595,6 +596,13 @@ void pci_iov_update_resource(struct pci_dev *dev, int resno)
if (!iov)
return;
+ pci_read_config_word(dev, iov->pos + PCI_SRIOV_CTRL, &cmd);
+ if ((cmd & PCI_SRIOV_CTRL_VFE) && (cmd & PCI_SRIOV_CTRL_MSE)) {
+ dev_WARN(&dev->dev, "can't update enabled VF BAR%d %pR\n",
+ vf_bar, res);
+ return;
+ }
+
/*
* Ignore unimplemented BARs, unused resource slots for 64-bit
* BARs, and non-movable resources, e.g., those described via
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 28, 2016 at 10:15:42PM -0600, Bjorn Helgaas wrote:
pci_std_update_resource() only deals with standard BARs, so we don't have
to worry about the complications of VF BARs in an SR-IOV capability.
Compute the BAR address inline and remove pci_resource_bar(). That makes
pci_iov_resource_bar() unused, so remove that as well.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
}
/**
- * pci_iov_resource_bar - get position of the SR-IOV BAR
- * @dev: the PCI device
- * @resno: the resource number
- *
- * Returns position of the BAR encapsulated in the SR-IOV capability.
- */
-int pci_iov_resource_bar(struct pci_dev *dev, int resno)
-{
- if (resno < PCI_IOV_RESOURCES || resno > PCI_IOV_RESOURCE_END)
- return 0;
-
- BUG_ON(!dev->is_physfn);
-
- return dev->sriov->pos + PCI_SRIOV_BAR +
- 4 * (resno - PCI_IOV_RESOURCES);
-}
-
-/**
* pci_iov_update_resource - update a VF BAR
* @dev: the PCI device
* @resno: the resource number
@@ -4827,36 +4827,6 @@ int pci_select_bars(struct pci_dev *dev, unsigned long flags)
}
EXPORT_SYMBOL(pci_select_bars);
-/**
- * pci_resource_bar - get position of the BAR associated with a resource
- * @dev: the PCI device
- * @resno: the resource number
- * @type: the BAR type to be filled in
- *
- * Returns BAR position in config space, or 0 if the BAR is invalid.
- */
-int pci_resource_bar(struct pci_dev *dev, int resno, enum pci_bar_type *type)
-{
- int reg;
-
- if (resno < PCI_ROM_RESOURCE) {
- *type = pci_bar_unknown;
- return PCI_BASE_ADDRESS_0 + 4 * resno;
- } else if (resno == PCI_ROM_RESOURCE) {
- *type = pci_bar_mem32;
- return dev->rom_base_reg;
- } else if (resno < PCI_BRIDGE_RESOURCES) {
- /* device specific resource */
- *type = pci_bar_unknown;
- reg = pci_iov_resource_bar(dev, resno);
- if (reg)
- return reg;
- }
-
- dev_err(&dev->dev, "BAR %d: invalid resource\n", resno);
- return 0;
-}
-
/* Some architectures require additional programming to enable VGA */
static arch_set_vga_state_t arch_set_vga_state;
On Mon, Nov 28, 2016 at 10:16:07PM -0600, Bjorn Helgaas wrote:
Remove the assumption that IORESOURCE_ROM_ENABLE == PCI_ROM_ADDRESS_ENABLE.
PCI_ROM_ADDRESS_ENABLE is the ROM enable bit defined by the PCI spec, so if
we're reading or writing a BAR register value, that's what we should use.
IORESOURCE_ROM_ENABLE is a corresponding bit in struct resource flags.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
mask64 = (u32)PCI_BASE_ADDRESS_MEM_MASK;
}
} else {
- res->flags |= (l & IORESOURCE_ROM_ENABLE);
+ if (l & PCI_ROM_ADDRESS_ENABLE)
+ res->flags |= IORESOURCE_ROM_ENABLE;
l64 = l & PCI_ROM_ADDRESS_MASK;
sz64 = sz & PCI_ROM_ADDRESS_MASK;
mask64 = (u32)PCI_ROM_ADDRESS_MASK;
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Nov 28, 2016 at 10:16:48PM -0600, Bjorn Helgaas wrote:
pci_update_resource() updates a hardware BAR so its address matches the
kernel's struct resource UNLESS it's a disabled ROM BAR. We only update
those when we enable the ROM.
It's not obvious from the code why ROM BARs should be handled specially.
Apparently there are Matrox devices with defective ROM BARs that read as
zero when disabled. That means that if pci_enable_rom() reads the disabled
BAR, sets PCI_ROM_ADDRESS_ENABLE (without re-inserting the address), and
writes it back, it would enable the ROM at address zero.
Add comments and references to explain why we can't make the code look more
rational.
The code changes are from 755528c860b0 ("Ignore disabled ROM resources at
setup") and 8085ce084c0f ("[PATCH] Fix PCI ROM mapping").
Link: https://lkml.org/lkml/2005/8/30/138
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
@@ -35,6 +35,11 @@ int pci_enable_rom(struct pci_dev *pdev)
if (res->flags & IORESOURCE_ROM_SHADOW)
return 0;
+ /*
+ * Ideally pci_update_resource() would update the ROM BAR address,
+ * and we would only set the enable bit here. But apparently some
+ * devices have buggy ROM BARs that read as zero when disabled.
+ */
pcibios_resource_to_bus(pdev->bus, ®ion, res);
pci_read_config_dword(pdev, pdev->rom_base_reg, &rom_addr);
rom_addr &= ~PCI_ROM_ADDRESS_MASK;
if (resno < PCI_ROM_RESOURCE) {
reg = PCI_BASE_ADDRESS_0 + 4 * resno;
} else if (resno == PCI_ROM_RESOURCE) {
+
+ /*
+ * Apparently some Matrox devices have ROM BARs that read
+ * as zero when disabled, so don't update ROM BARs unless
+ * they're enabled. See https://lkml.org/lkml/2005/8/30/138.
+ */
if (!(res->flags & IORESOURCE_ROM_ENABLE))
return;
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 29, 2016 at 03:55:46PM +1100, Gavin Shan wrote:
On Mon, Nov 28, 2016 at 10:15:06PM -0600, Bjorn Helgaas wrote:
quoted
Previously pci_update_resource() used the same code path for updating
standard BARs and VF BARs in SR-IOV capabilities.
Split the VF BAR update into a new pci_iov_update_resource() internal
interface, which makes it simpler to compute the BAR address (we can get
rid of pci_resource_bar() and pci_iov_resource_bar()).
This patch:
- Renames pci_update_resource() to pci_std_update_resource(),
- Adds pci_iov_update_resource(),
- Makes pci_update_resource() a wrapper that calls the appropriate one,
No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
With below minor comments fixed:
Reviewed-by: Gavin Shan <redacted>
@@ -571,6 +571,55 @@ int pci_iov_resource_bar(struct pci_dev *dev, int resno)
4 * (resno - PCI_IOV_RESOURCES);
}
+/**
+ * pci_iov_update_resource - update a VF BAR
+ * @dev: the PCI device
+ * @resno: the resource number
+ *
+ * Update a VF BAR in the SR-IOV capability of a PF.
+ */
+void pci_iov_update_resource(struct pci_dev *dev, int resno)
+{
+ struct pci_sriov *iov = dev->is_physfn ? dev->sriov : NULL;
+ struct resource *res = dev->resource + resno;
+ int vf_bar = resno - PCI_IOV_RESOURCES;
+ struct pci_bus_region region;
+ u32 new;
+ int reg;
+
+ /*
+ * The generic pci_restore_bars() path calls this for all devices,
+ * including VFs and non-SR-IOV devices. If this is not a PF, we
+ * have nothing to do.
+ */
+ if (!iov)
+ return;
+
+ /*
+ * Ignore unimplemented BARs, unused resource slots for 64-bit
+ * BARs, and non-movable resources, e.g., those described via
+ * Enhanced Allocation.
+ */
+ if (!res->flags)
+ return;
+
+ if (res->flags & IORESOURCE_UNSET)
+ return;
+
+ if (res->flags & IORESOURCE_PCI_FIXED)
+ return;
+
+ pcibios_resource_to_bus(dev->bus, ®ion, res);
+ new = region.start;
+
The bits indicating the BAR's property (e.g. memory, IO etc) are missed in @new.
Hmm, yes. I omitted those because those bits are supposed to be
read-only, per spec (PCI r3.0, sec 6.2.5.1). But I guess it would be
more conservative to keep them, and this shouldn't be needlessly
different from pci_std_update_resource().
However, I don't think this code in pci_update_resource() is obviously
correct:
new = region.start | (res->flags & PCI_REGION_FLAG_MASK);
PCI_REGION_FLAG_MASK is 0xf. For memory BARs, bits 0-3 are read-only
property bits. For I/O BARs, bits 0-1 are read-only and bits 2-3 are
part of the address, so on the face of it, the above could corrupt two
bits of an I/O address.
It's true that decode_bar() initializes flags correctly, using
PCI_BASE_ADDRESS_IO_MASK for I/O BARs and PCI_BASE_ADDRESS_MEM_MASK
for memory BARs, but it would take a little more digging to be sure
that we never set bits 2-3 of flags for an I/O resource elsewhere.
How about this in pci_std_update_resource():
pcibios_resource_to_bus(dev->bus, ®ion, res);
new = region.start;
if (res->flags & IORESOURCE_IO) {
mask = (u32)PCI_BASE_ADDRESS_IO_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_IO_MASK;
} else {
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
}
and this in pci_iov_update_resource():
pcibios_resource_to_bus(dev->bus, ®ion, res);
new = region.start;
new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
It shouldn't fix anything, but I think it is more obvious that we
can't corrupt bits 2-3 of an I/O BAR.
I think it was copied from pci_update_resource(). Why we can't just have "new = region.start >> 32"?
Right; I did copy this from pci_update_resource(). The changelog from
cf7bee5a0bf2 ("[PATCH] Fix restore of 64-bit PCI BAR's") says "Also
make sure to write high bits - use "x >> 16 >> 16" (rather than the
simpler ">> 32") to avoid warnings on 32-bit architectures where we're
not going to have any high bits."
I didn't take the time to revalidate whether that's still applicable.
quoted
+void pci_update_resource(struct pci_dev *dev, int resno)
+{
+ if (resno <= PCI_ROM_RESOURCE)
+ pci_std_update_resource(dev, resno);
+#ifdef CONFIG_PCI_IOV
+ else if (resno >= PCI_IOV_RESOURCES && resno < PCI_IOV_RESOURCE_END)
The last BAR is missed:
else if (resno >= PCI_IOV_RESOURCES && resno <= PCI_IOV_RESOURCE_END)
On Tue, Nov 29, 2016 at 08:48:26AM -0600, Bjorn Helgaas wrote:
On Tue, Nov 29, 2016 at 03:55:46PM +1100, Gavin Shan wrote:
quoted
On Mon, Nov 28, 2016 at 10:15:06PM -0600, Bjorn Helgaas wrote:
quoted
Previously pci_update_resource() used the same code path for updating
standard BARs and VF BARs in SR-IOV capabilities.
Split the VF BAR update into a new pci_iov_update_resource() internal
interface, which makes it simpler to compute the BAR address (we can get
rid of pci_resource_bar() and pci_iov_resource_bar()).
This patch:
- Renames pci_update_resource() to pci_std_update_resource(),
- Adds pci_iov_update_resource(),
- Makes pci_update_resource() a wrapper that calls the appropriate one,
No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
With below minor comments fixed:
Reviewed-by: Gavin Shan <redacted>
@@ -571,6 +571,55 @@ int pci_iov_resource_bar(struct pci_dev *dev, int resno)
4 * (resno - PCI_IOV_RESOURCES);
}
+/**
+ * pci_iov_update_resource - update a VF BAR
+ * @dev: the PCI device
+ * @resno: the resource number
+ *
+ * Update a VF BAR in the SR-IOV capability of a PF.
+ */
+void pci_iov_update_resource(struct pci_dev *dev, int resno)
+{
+ struct pci_sriov *iov = dev->is_physfn ? dev->sriov : NULL;
+ struct resource *res = dev->resource + resno;
+ int vf_bar = resno - PCI_IOV_RESOURCES;
+ struct pci_bus_region region;
+ u32 new;
+ int reg;
+
+ /*
+ * The generic pci_restore_bars() path calls this for all devices,
+ * including VFs and non-SR-IOV devices. If this is not a PF, we
+ * have nothing to do.
+ */
+ if (!iov)
+ return;
+
+ /*
+ * Ignore unimplemented BARs, unused resource slots for 64-bit
+ * BARs, and non-movable resources, e.g., those described via
+ * Enhanced Allocation.
+ */
+ if (!res->flags)
+ return;
+
+ if (res->flags & IORESOURCE_UNSET)
+ return;
+
+ if (res->flags & IORESOURCE_PCI_FIXED)
+ return;
+
+ pcibios_resource_to_bus(dev->bus, ®ion, res);
+ new = region.start;
+
The bits indicating the BAR's property (e.g. memory, IO etc) are missed in @new.
Hmm, yes. I omitted those because those bits are supposed to be
read-only, per spec (PCI r3.0, sec 6.2.5.1). But I guess it would be
more conservative to keep them, and this shouldn't be needlessly
different from pci_std_update_resource().
Yeah, Agree.
However, I don't think this code in pci_update_resource() is obviously
correct:
new = region.start | (res->flags & PCI_REGION_FLAG_MASK);
PCI_REGION_FLAG_MASK is 0xf. For memory BARs, bits 0-3 are read-only
property bits. For I/O BARs, bits 0-1 are read-only and bits 2-3 are
part of the address, so on the face of it, the above could corrupt two
bits of an I/O address.
It's true that decode_bar() initializes flags correctly, using
PCI_BASE_ADDRESS_IO_MASK for I/O BARs and PCI_BASE_ADDRESS_MEM_MASK
for memory BARs, but it would take a little more digging to be sure
that we never set bits 2-3 of flags for an I/O resource elsewhere.
The BAR's property bits are probed from device-tree, not hardware
on some platforms (e.g. pSeries). Also, there is only one (property)
bit if it's a ROM BAR. So more check as below might be needed because
the code (without the enhancement) should also work fine.
How about this in pci_std_update_resource():
pcibios_resource_to_bus(dev->bus, ®ion, res);
new = region.start;
if (res->flags & IORESOURCE_IO) {
mask = (u32)PCI_BASE_ADDRESS_IO_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_IO_MASK;
} else {
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
}
if (res->flags & IORESOURCE_IO) {
mask = (u32)PCI_BASE_ADDRESS_IO_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_IO_MASK;
} else if (resno < PCI_ROM_RESOURCE) {
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
} else if (resno == PCI_ROM_RESOURCE) {
mask = ~((u32)IORESOURCE_ROM_ENABLE);
new |= res->flags & IORESOURCE_ROM_ENABLE);
} else {
dev_warn(&dev->dev, "BAR#%d out of range\n", resno);
return;
}
and this in pci_iov_update_resource():
pcibios_resource_to_bus(dev->bus, ®ion, res);
new = region.start;
new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
It shouldn't fix anything, but I think it is more obvious that we
can't corrupt bits 2-3 of an I/O BAR.
Agree and the this part of changes look good to me.
I think it was copied from pci_update_resource(). Why we can't just have "new = region.start >> 32"?
Right; I did copy this from pci_update_resource(). The changelog from
cf7bee5a0bf2 ("[PATCH] Fix restore of 64-bit PCI BAR's") says "Also
make sure to write high bits - use "x >> 16 >> 16" (rather than the
simpler ">> 32") to avoid warnings on 32-bit architectures where we're
not going to have any high bits."
I didn't take the time to revalidate whether that's still applicable.
Ah, I see. I think we still need this on 32-bits systems.
quoted
quoted
+void pci_update_resource(struct pci_dev *dev, int resno)
+{
+ if (resno <= PCI_ROM_RESOURCE)
+ pci_std_update_resource(dev, resno);
+#ifdef CONFIG_PCI_IOV
+ else if (resno >= PCI_IOV_RESOURCES && resno < PCI_IOV_RESOURCE_END)
The last BAR is missed:
else if (resno >= PCI_IOV_RESOURCES && resno <= PCI_IOV_RESOURCE_END)
Ah, right, thanks!
quoted
quoted
+ pci_iov_update_resource(dev, resno);
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 30, 2016 at 10:20:28AM +1100, Gavin Shan wrote:
On Tue, Nov 29, 2016 at 08:48:26AM -0600, Bjorn Helgaas wrote:
quoted
On Tue, Nov 29, 2016 at 03:55:46PM +1100, Gavin Shan wrote:
quoted
On Mon, Nov 28, 2016 at 10:15:06PM -0600, Bjorn Helgaas wrote:
quoted
Previously pci_update_resource() used the same code path for updating
standard BARs and VF BARs in SR-IOV capabilities.
Split the VF BAR update into a new pci_iov_update_resource() internal
interface, which makes it simpler to compute the BAR address (we can get
rid of pci_resource_bar() and pci_iov_resource_bar()).
This patch:
- Renames pci_update_resource() to pci_std_update_resource(),
- Adds pci_iov_update_resource(),
- Makes pci_update_resource() a wrapper that calls the appropriate one,
No functional change intended.
quoted
However, I don't think this code in pci_update_resource() is obviously
correct:
new = region.start | (res->flags & PCI_REGION_FLAG_MASK);
PCI_REGION_FLAG_MASK is 0xf. For memory BARs, bits 0-3 are read-only
property bits. For I/O BARs, bits 0-1 are read-only and bits 2-3 are
part of the address, so on the face of it, the above could corrupt two
bits of an I/O address.
It's true that decode_bar() initializes flags correctly, using
PCI_BASE_ADDRESS_IO_MASK for I/O BARs and PCI_BASE_ADDRESS_MEM_MASK
for memory BARs, but it would take a little more digging to be sure
that we never set bits 2-3 of flags for an I/O resource elsewhere.
The BAR's property bits are probed from device-tree, not hardware
on some platforms (e.g. pSeries). Also, there is only one (property)
bit if it's a ROM BAR. So more check as below might be needed because
the code (without the enhancement) should also work fine.
Ah, right, I forgot about that. I didn't do enough digging :)
quoted
How about this in pci_std_update_resource():
pcibios_resource_to_bus(dev->bus, ®ion, res);
new = region.start;
if (res->flags & IORESOURCE_IO) {
mask = (u32)PCI_BASE_ADDRESS_IO_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_IO_MASK;
} else {
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
}
if (res->flags & IORESOURCE_IO) {
mask = (u32)PCI_BASE_ADDRESS_IO_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_IO_MASK;
} else if (resno < PCI_ROM_RESOURCE) {
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
} else if (resno == PCI_ROM_RESOURCE) {
mask = ~((u32)IORESOURCE_ROM_ENABLE);
new |= res->flags & IORESOURCE_ROM_ENABLE);
} else {
dev_warn(&dev->dev, "BAR#%d out of range\n", resno);
return;
}
After this patch, the only thing we OR into a ROM BAR value is
PCI_ROM_ADDRESS_ENABLE, and that's done below, only if the ROM is
already enabled.
I did update the ROM mask (to PCI_ROM_ADDRESS_MASK). I'm not 100%
sure about doing that -- it follows the spec, but it is a change from
what we've been doing before. I guess it should be safe because it
means we're checking fewer bits than before (only the top 21 bits for
ROMs, where we used check the top 28), so the only possible difference
is that we might not warn about "error updating" in some case where we
used to.
I'm not really sure about the value of the "error updating" checks to
begin with, though I guess it does help us find broken devices that
put non-BARs where BARs are supposed to be.
Bjorn
[Your response didn't make it to the list, I think because it's some
non-plaintext encoding that is rejected by the list (see
http://vger.kernel.org/majordomo-info.html)]
On Wed, Nov 30, 2016 at 11:56 AM, David Laight [off-list ref] wrote:
From: Bjorn Helgaas
quoted
Sent: 29 November 2016 04:15
If we update a VF BAR while it's enabled, there are two potential problems:
1) Any driver that's using the VF has a cached BAR value that is stale
after the update, and
2) We can't update 64-bit BARs atomically, so the intermediate state
(new lower dword with old upper dword) may conflict with another
device, and an access by a driver unrelated to the VF may cause a bus
error.
Can the high word be first set to a value that is invalid (ie a 4G block
that has no valid PCIe slaves) before updating the low word and finally
the correct high word.
Note that the address only has to be outside the range that the bridge
forwards onto that specific bus.
Maybe, but I think that's getting way too complicated. I think we
should just think of it as a higher level bug if we're trying to
update an enabled BAR. We might have to live with that scenario for
standard BARs because firmware might have enabled it for us, and
things might break if we disable it, but I don't think we should try
to make it work for VF BARs.
Bjorn
On Tue, Nov 29, 2016 at 06:06:05PM -0600, Bjorn Helgaas wrote:
On Wed, Nov 30, 2016 at 10:20:28AM +1100, Gavin Shan wrote:
quoted
On Tue, Nov 29, 2016 at 08:48:26AM -0600, Bjorn Helgaas wrote:
quoted
On Tue, Nov 29, 2016 at 03:55:46PM +1100, Gavin Shan wrote:
quoted
On Mon, Nov 28, 2016 at 10:15:06PM -0600, Bjorn Helgaas wrote:
quoted
Previously pci_update_resource() used the same code path for updating
standard BARs and VF BARs in SR-IOV capabilities.
Split the VF BAR update into a new pci_iov_update_resource() internal
interface, which makes it simpler to compute the BAR address (we can get
rid of pci_resource_bar() and pci_iov_resource_bar()).
This patch:
- Renames pci_update_resource() to pci_std_update_resource(),
- Adds pci_iov_update_resource(),
- Makes pci_update_resource() a wrapper that calls the appropriate one,
No functional change intended.
quoted
quoted
However, I don't think this code in pci_update_resource() is obviously
correct:
new = region.start | (res->flags & PCI_REGION_FLAG_MASK);
PCI_REGION_FLAG_MASK is 0xf. For memory BARs, bits 0-3 are read-only
property bits. For I/O BARs, bits 0-1 are read-only and bits 2-3 are
part of the address, so on the face of it, the above could corrupt two
bits of an I/O address.
It's true that decode_bar() initializes flags correctly, using
PCI_BASE_ADDRESS_IO_MASK for I/O BARs and PCI_BASE_ADDRESS_MEM_MASK
for memory BARs, but it would take a little more digging to be sure
that we never set bits 2-3 of flags for an I/O resource elsewhere.
The BAR's property bits are probed from device-tree, not hardware
on some platforms (e.g. pSeries). Also, there is only one (property)
bit if it's a ROM BAR. So more check as below might be needed because
the code (without the enhancement) should also work fine.
Ah, right, I forgot about that. I didn't do enough digging :)
quoted
quoted
How about this in pci_std_update_resource():
pcibios_resource_to_bus(dev->bus, ®ion, res);
new = region.start;
if (res->flags & IORESOURCE_IO) {
mask = (u32)PCI_BASE_ADDRESS_IO_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_IO_MASK;
} else {
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
}
if (res->flags & IORESOURCE_IO) {
mask = (u32)PCI_BASE_ADDRESS_IO_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_IO_MASK;
} else if (resno < PCI_ROM_RESOURCE) {
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
} else if (resno == PCI_ROM_RESOURCE) {
mask = ~((u32)IORESOURCE_ROM_ENABLE);
new |= res->flags & IORESOURCE_ROM_ENABLE);
} else {
dev_warn(&dev->dev, "BAR#%d out of range\n", resno);
return;
}
After this patch, the only thing we OR into a ROM BAR value is
PCI_ROM_ADDRESS_ENABLE, and that's done below, only if the ROM is
already enabled.
I did update the ROM mask (to PCI_ROM_ADDRESS_MASK). I'm not 100%
sure about doing that -- it follows the spec, but it is a change from
what we've been doing before. I guess it should be safe because it
means we're checking fewer bits than before (only the top 21 bits for
ROMs, where we used check the top 28), so the only possible difference
is that we might not warn about "error updating" in some case where we
used to.
I'm not really sure about the value of the "error updating" checks to
begin with, though I guess it does help us find broken devices that
put non-BARs where BARs are supposed to be.
Yeah, agree. Bjorn, I don't have more comments. please take your time
to respin the series and maybe applied it. I really want to see the
fixes can be in 4.10 if possible :-)
Thanks,
Gavin
On Thu, Dec 01, 2016 at 10:02:54AM +1100, Gavin Shan wrote:
On Tue, Nov 29, 2016 at 06:06:05PM -0600, Bjorn Helgaas wrote:
quoted
On Wed, Nov 30, 2016 at 10:20:28AM +1100, Gavin Shan wrote:
quoted
On Tue, Nov 29, 2016 at 08:48:26AM -0600, Bjorn Helgaas wrote:
quoted
On Tue, Nov 29, 2016 at 03:55:46PM +1100, Gavin Shan wrote:
quoted
On Mon, Nov 28, 2016 at 10:15:06PM -0600, Bjorn Helgaas wrote:
quoted
Previously pci_update_resource() used the same code path for updating
standard BARs and VF BARs in SR-IOV capabilities.
Split the VF BAR update into a new pci_iov_update_resource() internal
interface, which makes it simpler to compute the BAR address (we can get
rid of pci_resource_bar() and pci_iov_resource_bar()).
This patch:
- Renames pci_update_resource() to pci_std_update_resource(),
- Adds pci_iov_update_resource(),
- Makes pci_update_resource() a wrapper that calls the appropriate one,
No functional change intended.
quoted
quoted
However, I don't think this code in pci_update_resource() is obviously
correct:
new = region.start | (res->flags & PCI_REGION_FLAG_MASK);
PCI_REGION_FLAG_MASK is 0xf. For memory BARs, bits 0-3 are read-only
property bits. For I/O BARs, bits 0-1 are read-only and bits 2-3 are
part of the address, so on the face of it, the above could corrupt two
bits of an I/O address.
It's true that decode_bar() initializes flags correctly, using
PCI_BASE_ADDRESS_IO_MASK for I/O BARs and PCI_BASE_ADDRESS_MEM_MASK
for memory BARs, but it would take a little more digging to be sure
that we never set bits 2-3 of flags for an I/O resource elsewhere.
The BAR's property bits are probed from device-tree, not hardware
on some platforms (e.g. pSeries). Also, there is only one (property)
bit if it's a ROM BAR. So more check as below might be needed because
the code (without the enhancement) should also work fine.
Ah, right, I forgot about that. I didn't do enough digging :)
quoted
quoted
How about this in pci_std_update_resource():
pcibios_resource_to_bus(dev->bus, ®ion, res);
new = region.start;
if (res->flags & IORESOURCE_IO) {
mask = (u32)PCI_BASE_ADDRESS_IO_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_IO_MASK;
} else {
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
}
if (res->flags & IORESOURCE_IO) {
mask = (u32)PCI_BASE_ADDRESS_IO_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_IO_MASK;
} else if (resno < PCI_ROM_RESOURCE) {
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
} else if (resno == PCI_ROM_RESOURCE) {
mask = ~((u32)IORESOURCE_ROM_ENABLE);
new |= res->flags & IORESOURCE_ROM_ENABLE);
} else {
dev_warn(&dev->dev, "BAR#%d out of range\n", resno);
return;
}
After this patch, the only thing we OR into a ROM BAR value is
PCI_ROM_ADDRESS_ENABLE, and that's done below, only if the ROM is
already enabled.
I did update the ROM mask (to PCI_ROM_ADDRESS_MASK). I'm not 100%
sure about doing that -- it follows the spec, but it is a change from
what we've been doing before. I guess it should be safe because it
means we're checking fewer bits than before (only the top 21 bits for
ROMs, where we used check the top 28), so the only possible difference
is that we might not warn about "error updating" in some case where we
used to.
I'm not really sure about the value of the "error updating" checks to
begin with, though I guess it does help us find broken devices that
put non-BARs where BARs are supposed to be.
Yeah, agree. Bjorn, I don't have more comments. please take your time
to respin the series and maybe applied it. I really want to see the
fixes can be in 4.10 if possible :-)
These will definitely be in v4.10. Thanks for all your help!
On Wed, Nov 30, 2016 at 05:45:18PM -0600, Bjorn Helgaas wrote:
On Thu, Dec 01, 2016 at 10:02:54AM +1100, Gavin Shan wrote:
quoted
On Tue, Nov 29, 2016 at 06:06:05PM -0600, Bjorn Helgaas wrote:
quoted
On Wed, Nov 30, 2016 at 10:20:28AM +1100, Gavin Shan wrote:
quoted
On Tue, Nov 29, 2016 at 08:48:26AM -0600, Bjorn Helgaas wrote:
quoted
On Tue, Nov 29, 2016 at 03:55:46PM +1100, Gavin Shan wrote:
quoted
On Mon, Nov 28, 2016 at 10:15:06PM -0600, Bjorn Helgaas wrote:
quoted
Previously pci_update_resource() used the same code path for updating
standard BARs and VF BARs in SR-IOV capabilities.
Split the VF BAR update into a new pci_iov_update_resource() internal
interface, which makes it simpler to compute the BAR address (we can get
rid of pci_resource_bar() and pci_iov_resource_bar()).
This patch:
- Renames pci_update_resource() to pci_std_update_resource(),
- Adds pci_iov_update_resource(),
- Makes pci_update_resource() a wrapper that calls the appropriate one,
No functional change intended.
quoted
quoted
However, I don't think this code in pci_update_resource() is obviously
correct:
new = region.start | (res->flags & PCI_REGION_FLAG_MASK);
PCI_REGION_FLAG_MASK is 0xf. For memory BARs, bits 0-3 are read-only
property bits. For I/O BARs, bits 0-1 are read-only and bits 2-3 are
part of the address, so on the face of it, the above could corrupt two
bits of an I/O address.
It's true that decode_bar() initializes flags correctly, using
PCI_BASE_ADDRESS_IO_MASK for I/O BARs and PCI_BASE_ADDRESS_MEM_MASK
for memory BARs, but it would take a little more digging to be sure
that we never set bits 2-3 of flags for an I/O resource elsewhere.
The BAR's property bits are probed from device-tree, not hardware
on some platforms (e.g. pSeries). Also, there is only one (property)
bit if it's a ROM BAR. So more check as below might be needed because
the code (without the enhancement) should also work fine.
Ah, right, I forgot about that. I didn't do enough digging :)
quoted
quoted
How about this in pci_std_update_resource():
pcibios_resource_to_bus(dev->bus, ®ion, res);
new = region.start;
if (res->flags & IORESOURCE_IO) {
mask = (u32)PCI_BASE_ADDRESS_IO_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_IO_MASK;
} else {
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
}
if (res->flags & IORESOURCE_IO) {
mask = (u32)PCI_BASE_ADDRESS_IO_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_IO_MASK;
} else if (resno < PCI_ROM_RESOURCE) {
mask = (u32)PCI_BASE_ADDRESS_MEM_MASK;
new |= res->flags & ~PCI_BASE_ADDRESS_MEM_MASK;
} else if (resno == PCI_ROM_RESOURCE) {
mask = ~((u32)IORESOURCE_ROM_ENABLE);
new |= res->flags & IORESOURCE_ROM_ENABLE);
} else {
dev_warn(&dev->dev, "BAR#%d out of range\n", resno);
return;
}
After this patch, the only thing we OR into a ROM BAR value is
PCI_ROM_ADDRESS_ENABLE, and that's done below, only if the ROM is
already enabled.
I did update the ROM mask (to PCI_ROM_ADDRESS_MASK). I'm not 100%
sure about doing that -- it follows the spec, but it is a change from
what we've been doing before. I guess it should be safe because it
means we're checking fewer bits than before (only the top 21 bits for
ROMs, where we used check the top 28), so the only possible difference
is that we might not warn about "error updating" in some case where we
used to.
I'm not really sure about the value of the "error updating" checks to
begin with, though I guess it does help us find broken devices that
put non-BARs where BARs are supposed to be.
Yeah, agree. Bjorn, I don't have more comments. please take your time
to respin the series and maybe applied it. I really want to see the
fixes can be in 4.10 if possible :-)
These will definitely be in v4.10. Thanks for all your help!
On Mon, Nov 28, 2016 at 10:13:41PM -0600, Bjorn Helgaas wrote:
This is a v4 of Gavin's series for handling VF BAR updates. The
important piece is the first patch ("PCI: Do any VF BAR updates before
enabling the BARs"). That makes sure that if we update VF BARs, we do
it before enabling the VFs, and that is unchanged from v3.
The second patch in Gavin's series ("PCI: Disable VF's memory space on
updating IOV BAR in pci_update_resource()") temporarily disabled VF
memory space during an update. Since the first patch does the update
before enabling VFs, this case shouldn't happen in practice.
But even if we want to update a VF BAR while VF memory space is
enabled, I think temporarily disabling it is wrong. So I replaced
the second patch with a few patches that make that such an update
fail.
Please comment. These are on my pci/virtualization branch.
Changelog
=========
v4:
* Don't disable VF's memory space when IOV BARs are updated; fail the
update instead.
* Split IOV BAR updates from standard BAR updates so IOV updates can go
in pci/iov.c.
* Remove pci_resource_bar() and pci_iov_resource_bar() (the relevant
code is simpler when inlined into the callers).
* Cleanup IORESOURCE_ROM_ENABLE usage.
* Add comments about why ROMs are updated differently.
v3:
* Disable VF's memory space when IOV BARs are updated in
pcibios_sriov_enable().
v2:
* Added one patch calling pcibios_sriov_enable() before the VF
and VF BARs are enabled.
---
Bjorn Helgaas (6):
PCI: Ignore BAR updates on virtual functions
PCI: Separate VF BAR updates from standard BAR updates
PCI: Don't update VF BARs while VF memory space is enabled
PCI: Remove pci_resource_bar() and pci_iov_resource_bar()
PCI: Decouple IORESOURCE_ROM_ENABLE and PCI_ROM_ADDRESS_ENABLE
PCI: Add comments about ROM BAR updating
Gavin Shan (1):
PCI: Do any VF BAR updates before enabling the BARs
drivers/pci/iov.c | 69 +++++++++++++++++++++++++++++++++++++----------
drivers/pci/pci.c | 34 -----------------------
drivers/pci/pci.h | 7 +----
drivers/pci/probe.c | 3 +-
drivers/pci/rom.c | 5 +++
drivers/pci/setup-res.c | 37 ++++++++++++++++++-------
6 files changed, 88 insertions(+), 67 deletions(-)