All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 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.