From: Alexander Duyck <alexander.duyck@gmail.com>
To: Wei Yang <weiyang@linux.vnet.ibm.com>
Cc: ethan zhao <ethan.zhao@oracle.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Alexander Duyck <aduyck@mirantis.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 5/7] PCI: Wait 1 second between disabling VFs and clearing NumVFs
Date: Mon, 2 Nov 2015 07:46:24 -0800 [thread overview]
Message-ID: <56378550.4080209@gmail.com> (raw)
In-Reply-To: <20151102083334.GC1120@richards-mbp.cn.ibm.com>
On 11/02/2015 12:33 AM, Wei Yang wrote:
> On Fri, Oct 30, 2015 at 08:57:17AM -0700, Alexander Duyck wrote:
>> On 10/29/2015 11:00 PM, ethan zhao wrote:
>>> Wei,
>>>
>>> On 2015/10/30 13:14, Wei Yang wrote:
>>>> On Thu, Oct 29, 2015 at 05:23:22PM -0500, Bjorn Helgaas wrote:
>>>>> From: Alexander Duyck <aduyck@mirantis.com>
>>>>>
>>>>> Per sec 3.3.3.1 of the SR-IOV spec, r1.1, we must allow 1.0s after
>>>>> clearing
>>>>> VF Enable before reading any field in the SR-IOV Extended Capability.
>>>>>
>>>>> Wait 1 second before calling pci_iov_set_numvfs(), which reads
>>>>> PCI_SRIOV_VF_OFFSET and PCI_SRIOV_VF_STRIDE after it sets
>>>>> PCI_SRIOV_NUM_VF.
>>>>>
>>>>> [bhelgaas: split to separate patch for reviewability, add spec
>>>>> reference]
>>>>> Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
>>>>> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
>>>>> ---
>>>>> drivers/pci/iov.c | 2 +-
>>>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
>>>>> index fada98d..24428d5 100644
>>>>> --- a/drivers/pci/iov.c
>>>>> +++ b/drivers/pci/iov.c
>>>>> @@ -339,13 +339,13 @@ failed:
>>>>> iov->ctrl &= ~(PCI_SRIOV_CTRL_VFE | PCI_SRIOV_CTRL_MSE);
>>>>> pci_cfg_access_lock(dev);
>>>>> pci_write_config_word(dev, iov->pos + PCI_SRIOV_CTRL, iov->ctrl);
>>>>> - pci_iov_set_numvfs(dev, 0);
>>>>> ssleep(1);
>>>>> pci_cfg_access_unlock(dev);
>>>>>
>>>>> if (iov->link != dev->devfn)
>>>>> sysfs_remove_link(&dev->dev.kobj, "dep_link");
>>>>>
>>>>> + pci_iov_set_numvfs(dev, 0);
>>>> One small question, any specific reason put it here instead of just after
>>>> sleep()?
>>> Agree, pci_iov_set_numvfs(dev, 0) should be put before
>>> pci_cfg_access_unlock(dev) to avoid race, because "NumVFs may only be
>>> written while VF Enable is Clear"
>> We are already guaranteeing that aren't we? I'm assuming there is already
>> code in place here somewhere that prevents us from both enabling and
>> disabling SR-IOV from more than one thread. Otherwise how could we hope to
>> have any sort of consistent state?
>>
>> I'm fine with us being more explicit about it if we want to be, but if we are
>> going to do it we should probably update all 3 spots where we update NumVFs
>> after init instead of just this one. Perhaps it should be a separate patch.
>>
> Yep, I think the statement is met, "NumVFs may only be written while VF Enable
> is Clear".
>
> While in your commit log, the purpose of this patch is to wait 1 second before
> write NumVFs. So I am interesting to know why you move this out of the
> pci_cfg_access_lock. Because it looks better? have better performance?
>
> Actually, this is a question instead of a challenge :-)
It is because the first call to pci_iov_set_numvfs is done outside of
the pci_cfg_access_lock. This way when I add the clean-up for the bus
numbering failure in patch 7 I don't have to modify as much code either
since the write is already pulled out.
An added bonus is the code is now much closer to what we have in
sriov_disable which has seen much more use than the exception handling
case for sriov_enable, so it has been more thoroughly tested.
- Alex
next prev parent reply other threads:[~2015-11-02 15:46 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-29 22:22 [PATCH v2 0/7] SR-IOV fixes and cleanup Bjorn Helgaas
2015-10-29 22:22 ` [PATCH v2 1/7] PCI: Set SR-IOV NumVFs to zero after enumeration Bjorn Helgaas
2015-10-30 3:48 ` Wei Yang
2015-10-30 5:25 ` Wei Yang
2015-10-30 15:40 ` Alexander Duyck
2015-11-02 7:28 ` Wei Yang
2015-10-29 22:23 ` [PATCH v2 2/7] PCI: Remove redundant validation of SR-IOV offset/stride registers Bjorn Helgaas
2015-10-30 5:08 ` Wei Yang
2015-10-29 22:23 ` [PATCH v2 3/7] PCI: Remove VFs in reverse order if virtfn_add() fails Bjorn Helgaas
2015-10-30 5:09 ` Wei Yang
2015-10-29 22:23 ` [PATCH v2 4/7] PCI: Reorder pcibios_sriov_disable() Bjorn Helgaas
2015-10-30 5:09 ` Wei Yang
2015-10-29 22:23 ` [PATCH v2 5/7] PCI: Wait 1 second between disabling VFs and clearing NumVFs Bjorn Helgaas
2015-10-30 5:14 ` Wei Yang
2015-10-30 6:00 ` ethan zhao
2015-10-30 15:57 ` Alexander Duyck
2015-11-02 8:33 ` Wei Yang
2015-11-02 15:46 ` Alexander Duyck [this message]
2015-11-03 2:01 ` Wei Yang
2015-11-03 2:04 ` Wei Yang
2015-10-29 22:23 ` [PATCH v2 6/7] PCI: Fix sriov_enable() error path for pcibios_enable_sriov() failures Bjorn Helgaas
2015-10-30 5:18 ` Wei Yang
2015-10-29 22:23 ` [PATCH v2 7/7] PCI: Set NumVFs before computing how many buses VFs require Bjorn Helgaas
2015-10-30 5:22 ` Wei Yang
2015-10-30 16:03 ` Alexander Duyck
2015-11-02 8:27 ` Wei Yang
2015-11-02 15:39 ` Alexander Duyck
2015-11-03 2:18 ` Wei Yang
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=56378550.4080209@gmail.com \
--to=alexander.duyck@gmail.com \
--cc=aduyck@mirantis.com \
--cc=bhelgaas@google.com \
--cc=ethan.zhao@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=weiyang@linux.vnet.ibm.com \
/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