linux-kernel - Re: [PATCH] PCI: Init NumVFs register to zero in sriov

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABawtvPf3dCnRy2rcXKTbuXD6LzWHx9WE33mGqaUvjotS48NkQ@mail.gmail.com>
Date:	Sat, 16 Nov 2013 10:09:55 +0800
From:	Ethan Zhao <ethan.kernel@...il.com>
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Yu Zhao <yu.zhao@...el.com>, Bjorn Helgaas <bhelgaas@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] PCI: Init NumVFs register to zero in sriov_init()

On Fri, Nov 15, 2013 at 2:59 PM, Yinghai Lu <yinghai@...nel.org> wrote:
> On Wed, Nov 13, 2013 at 5:57 PM, Ethan Zhao <ethan.kernel@...il.com> wrote:
>> On Wed, Nov 6, 2013 at 10:49 PM, ethan.zhao <ethan.kernel@...il.com> wrote:
>>> Though no specification about NumVFs register initial value after POST, to void the confusion
>>> lspci output as following before VF was enabled, we should clear the NumVFs value left by BIOS
>>> to zero:
>
> Does BIOS need to clear it?

No, don't think BIOS need to clear it, according to the SR-IOV and PCI
specification, BIOS hasn't the responsibility to clear NumVFs register
 or not.  "The initial value of NumVFs is undefined." (SINGLE ROOT I/O
VIRTUALIZATION AND SHARING SPECIFICATION, REV. 1.1 chapter 3.3.7 ).
In fact, Linux doesn't trust the PCI_SRIOV_XX registers initial value
left by BIOS, exactly, it did in iov.c , Linux will re-initialize the
PCI_SRIOV_XX registers' value whatever their original value left by
BIOS.

static int sriov_init(struct pci_dev *dev, int pos)
{
  ... ...
  pci_read_config_word(dev, pos + PCI_SRIOV_CTRL, &ctrl);
  if (ctrl & PCI_SRIOV_CTRL_VFE) {
  pci_write_config_word(dev, pos + PCI_SRIOV_CTRL, 0);
  ssleep(1);
  }

... ...
ctrl = 0;
... ...
found:
pci_write_config_word(dev, pos + PCI_SRIOV_CTRL, ctrl);
... ...
}

If so, why leave  value of NumVFs register un-initialized, till be
exposed to user via lspci etc.

>
>
>>>
>>> $lspci -vvv -s 03:00.0
>>> Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)
>>> ~
>>> Capabilities: [160 v1] Single Root I/O Virtualization (SR-IOV)
>>>                 IOVCap: Migration-, Interrupt Message Number: 000
>>>                 IOVCtl: Enable+ Migration- Interrupt- MSE+ ARIHierarchy+
>>>                 IOVSta: Migration-
>>>                 Initial VFs: 64, Total VFs: 64, Number of VFs: 64, Function Dependency Link: 00
>>>                                                                            ^dazed !
>>> ~
>
> just display problem?

So far, only catch the issue via lspci, "seems' only confuses user,
the VFs are enabled to 64. in fact, they are disabled. but it is not
bug of lspci, binary dump of lspci could prove it.


Thanks,
Ethan
>
>>> Signed-off-by: ethan.zhao <ethan.kernel@...il.com>
>>> ---
>>>  drivers/pci/iov.c | 2 ++
>>>  1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
>>> index de8ffac..a4941ad 100644
>>> --- a/drivers/pci/iov.c
>>> +++ b/drivers/pci/iov.c
>>> @@ -439,6 +439,8 @@ static int sriov_init(struct pci_dev *dev, int pos)
>>>
>>>  found:
>>>         pci_write_config_word(dev, pos + PCI_SRIOV_CTRL, ctrl);
>>> +       /* VF Enable is cleared, so we could init the NumVFs register to 0 */
>>> +       pci_write_config_word(dev, pos + PCI_SRIOV_NUM_VF, 0);
>>>         pci_read_config_word(dev, pos + PCI_SRIOV_VF_OFFSET, &offset);
>>>         pci_read_config_word(dev, pos + PCI_SRIOV_VF_STRIDE, &stride);
>>>         if (!offset || (total > 1 && !stride))
>
> Thanks
>
> Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/