From: Gavin Shan <gwshan@linux.vnet.ibm.com>
To: Benjamin Herrenschmidt <benh@au1.ibm.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
Gavin Shan <gwshan@linux.vnet.ibm.com>,
bhelgaas@google.com, linux-pci@vger.kernel.org,
clsoto@us.ibm.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] PCI: Add parameter @mmio_force_on to pci_update_resource()
Date: Wed, 28 Sep 2016 09:37:49 +1000 [thread overview]
Message-ID: <20160927233749.GA19797@gwshan> (raw)
In-Reply-To: <1475012732.2857.293.camel@au1.ibm.com>
On Wed, Sep 28, 2016 at 07:45:32AM +1000, Benjamin Herrenschmidt wrote:
>On Tue, 2016-09-27 at 14:20 -0500, Bjorn Helgaas wrote:
>> On Mon, Sep 19, 2016 at 09:53:30AM +1000, Gavin Shan wrote:
>> > In pci_update_resource(), the PCI device's memory decoding (0x2 in
>> > PCI_COMMAND) is disabled when 64-bits memory BAR is updated if the
>> > PCI device's memory space wasn't asked to be always on by @pdev->
>> > mmio_always_on. The PF's memory decoding might be disabled when
>> > updating its IOV BARs in the following path. Actually, the PF's
>> > memory decoding shouldn't be disabled in this scenario as the PF
>> > has been started to provide services:
>>
>> The reason we disable memory decoding while updating a 64-bit BAR is
>> because we can't do the update atomically, and a half-updated BAR might
>> conflict with other devices.
>>
>> You need to explain what is special about these SR-IOV BARs that makes it
>> safe to update them non-atomically while decoding is enabled.
>
>The IOV BAR won't decode until SR-IOV is enabled right ? Gavin, I don't
>think we update it "live", so it should be safe...
>
Yeah, it's safe to update it with memory decoding on. As the function call
flow I listed in the changelog (as below), nobody should access the IOV BAR
when pci_update_resource() is called. However, the PF's memory BARs might
be accessed that time and it's not safe to disable PF's memory decoding.
sriov_numvfs_store
pdev->driver->sriov_configure
mlx5_core_sriov_configure
pci_enable_sriov
sriov_enable
pcibios_sriov_enable
pnv_pci_sriov_enable
pnv_pci_vf_resource_shift
pci_update_resource
Thanks,
Gavin
next prev parent reply other threads:[~2016-09-27 23:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-18 23:53 [PATCH] PCI: Add parameter @mmio_force_on to pci_update_resource() Gavin Shan
2016-09-26 23:43 ` Gavin Shan
2016-09-27 19:20 ` Bjorn Helgaas
2016-09-27 21:45 ` Benjamin Herrenschmidt
2016-09-27 23:37 ` Gavin Shan [this message]
2016-09-28 0:06 ` Benjamin Herrenschmidt
2016-09-28 1:14 ` Gavin Shan
2016-09-29 23:45 ` Gavin Shan
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=20160927233749.GA19797@gwshan \
--to=gwshan@linux.vnet.ibm.com \
--cc=benh@au1.ibm.com \
--cc=bhelgaas@google.com \
--cc=clsoto@us.ibm.com \
--cc=helgaas@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.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 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.