On Wed, Nov 23, 2016 at 05:49:10PM -0600, Bjorn Helgaas wrote: > On Wed, Oct 26, 2016 at 12:15:34PM +1100, Gavin Shan wrote: > > This moves pcibios_sriov_enable() to the point before VF and VF BARs > > are enabled on PowerNV platform. Also, pci_update_resource() is used > > to update IOV BARs on PowerNV platform, the PF might have been functional > > when the function is called. We shouldn't disable PF's memory decoding > > at that point. Instead, the VF's memory space should be disabled. > > > > Changelog > > ========= > > 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. > > > > Gavin Shan (2): > > PCI: Call pcibios_sriov_enable() before IOV BARs are enabled > > PCI: Disable VF's memory space on updating IOV BAR in > > pci_update_resource() > > > > drivers/pci/iov.c | 14 +++++++------- > > drivers/pci/setup-res.c | 28 ++++++++++++++++++++-------- > > 2 files changed, 27 insertions(+), 15 deletions(-) > > I applied these to pci/virtualization for v4.10. Thanks for your > patience, Gavin. This nagged at me over the holidays, and I think that if the VF has memory decoding enabled, it's wrong to allow a VF BAR to be updated, even if we temporarily disable memory decoding. If the VF is enabled, a driver may have claimed it, and that means the driver probably has ioremapped the BAR, and if we update the BAR, that ioremap is now stale. The driver has no idea that anything changed. Of course, we may know that pci_update_resource() is never called after a driver has claimed the VF, but I think it's much better to restructure the callers so the VF BAR updates happen *before* enabling the VFs, as you did in patch 1. Once we have that, there's no point in temporarily disabling memory decoding, so I worked up some patches to make the update fail. I'll post those in a minute and you can see what you think. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html