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: <CABawtvNHbRKdCXcfa-fOcS-7kA1TqBey+h+8QFFUtfYWwVRW8w@mail.gmail.com>
Date:	Thu, 21 Nov 2013 10:01:44 +0800
From:	Ethan Zhao <ethan.kernel@...il.com>
To:	Bjorn Helgaas <bhelgaas@...gle.com>
Cc:	Yu Zhao <yu.zhao@...el.com>, Yinghai Lu <yinghai@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: [PATCH] PCI: Init NumVFs register to zero in sriov_init()

Bjorn,
    I revised the description part with the original bug material as
below, help to take a look, will send V2 back to home, SMTP blocked by
company network.

    PCI: Init NumVFs register to zero in sriov_init()

    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:

    #lspci -vvvxxx -s 13:00.0
   13:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+
    Network Connection (rev 01)  Subsystem: Oracle/SUN Ethernet Server
Adapter X520-2
    ~
    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 !
    140: 03 00 01 15 c4 24 c8 ff ff 21 1b 00 00 00 00 00
    150: 0e 00 01 16 00 01 00 00 00 00 00 00 00 00 00 00
    160: 10 00 01 00 00 00 00 00 10 00 00 00 40 00 40 00

          ^        ^Total VFs

          Initial VFs
    170: 40 00 00 00 80 00 02 00 00 00 ed 10 53 05 00 00
             ^Number of VFs


Thanks,
Ethan


On Wed, Nov 20, 2013 at 8:07 AM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
> On Tue, Nov 19, 2013 at 3:24 PM, Bjorn Helgaas <bhelgaas@...gle.com> wrote:
>> [+cc linux-pci]
>>
>> On Wed, Nov 6, 2013 at 7:49 AM, 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:
>>>
>>> $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 !
>
> Did you mean to show lspci output from before SR-IOV was enabled?  It
> looks like SR-IOV is enabled here, so I don't think your patch would
> change this output at all.
>
> Bjorn
--
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/