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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date:   Tue, 3 Sep 2019 09:33:31 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Андрей Леончиков 
        <andreil499@...il.com>
Cc:     bhelgaas@...gle.com, linux-pci@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Andrei Leonchikov <andreil499@...il.com>
Subject: Re: [PATCH 1/1] Fix ARI enabling for a NVME devices

[adding back the Cc list]

On Tue, Sep 03, 2019 at 07:24:15PM +0300, Андрей Леончиков wrote:
> All drives has ARI capability, but everywhere the PCI_EXP_DEVCAP2_ARI
> in the DEVCAP2 register is reset (see NVMe specification, bit 5).
> At the same time, when the device is initialized, the DEVSAP register is
> requested and this bit is checked. And if it is reset, ARI will never turn
> on.
> Because of this, it will be impossible to correctly initialize more than 8
> functions per interface (1 physical and 7 virtual).
> At the moment we are developing a disk, one of the requirements for
> which is the correct operation of up to 128 virtual functions on one
> interface.
> During testing of this device, this behavior was noticed.

Looking at the PCIe spec this bit actually means "ARI forwarding
supported" and isn't the actual ARI support.  And the PCIe spec says
about that:

"Applicable only to Switch
Downstream Ports and Root Ports; must be 0b for other
Function types. This bit must be set to 1b if a Switch
Downstream Port or Root Port supports this optional capability.
See Section 6.13 for additional details."

So I don't see how we'd ever see this bit set on an actual NVMe device.

And yes, the name for our define is a little misnamed.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ