linux-kernel - RE: [PATCH v4 00/25] Add support for OpenCAPI Persistent Memory devices

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 02 Apr 2020 14:42:29 +1100
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Alastair D'Silva <alastair@...ilva.org>,
        'Dan Williams' <dan.j.williams@...el.com>
Cc:     "'Aneesh Kumar K . V'" <aneesh.kumar@...ux.ibm.com>,
        'Oliver O'Halloran' <oohall@...il.com>,
        'Benjamin Herrenschmidt' <benh@...nel.crashing.org>,
        'Paul Mackerras' <paulus@...ba.org>,
        'Frederic Barrat' <fbarrat@...ux.ibm.com>,
        'Andrew Donnellan' <ajd@...ux.ibm.com>,
        'Arnd Bergmann' <arnd@...db.de>,
        'Greg Kroah-Hartman' <gregkh@...uxfoundation.org>,
        'Vishal Verma' <vishal.l.verma@...el.com>,
        'Dave Jiang' <dave.jiang@...el.com>,
        'Ira Weiny' <ira.weiny@...el.com>,
        'Andrew Morton' <akpm@...ux-foundation.org>,
        'Mauro Carvalho Chehab' <mchehab+samsung@...nel.org>,
        "'David S. Miller'" <davem@...emloft.net>,
        'Rob Herring' <robh@...nel.org>,
        'Anton Blanchard' <anton@...abs.org>,
        'Krzysztof Kozlowski' <krzk@...nel.org>,
        'Mahesh Salgaonkar' <mahesh@...ux.vnet.ibm.com>,
        'Madhavan Srinivasan' <maddy@...ux.vnet.ibm.com>,
        'Cédric Le Goater' <clg@...d.org>,
        'Anju T Sudhakar' <anju@...ux.vnet.ibm.com>,
        'Hari Bathini' <hbathini@...ux.ibm.com>,
        'Thomas Gleixner' <tglx@...utronix.de>,
        'Greg Kurz' <groug@...d.org>,
        'Nicholas Piggin' <npiggin@...il.com>,
        'Masahiro Yamada' <yamada.masahiro@...ionext.com>,
        'Alexey Kardashevskiy' <aik@...abs.ru>,
        'Linux Kernel Mailing List' <linux-kernel@...r.kernel.org>,
        'linuxppc-dev' <linuxppc-dev@...ts.ozlabs.org>,
        'linux-nvdimm' <linux-nvdimm@...ts.01.org>,
        'Linux MM' <linux-mm@...ck.org>
Subject: RE: [PATCH v4 00/25] Add support for OpenCAPI Persistent Memory devices

"Alastair D'Silva" <alastair@...ilva.org> writes:
>> -----Original Message-----
>> From: Dan Williams <dan.j.williams@...el.com>
>> 
>> On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva <alastair@...ilva.org>
>> wrote:
>> >
>> > This series adds support for OpenCAPI Persistent Memory devices on
>> > bare metal (arch/powernv), exposing them as nvdimms so that we can
>> > make use of the existing infrastructure. There already exists a driver
>> > for the same devices abstracted through PowerVM (arch/pseries):
>> > arch/powerpc/platforms/pseries/papr_scm.c
>> >
>> > These devices are connected via OpenCAPI, and present as LPC (lowest
>> coherence point) memory to the system, practically, that means that
>> memory on these cards could be treated as conventional, cache-coherent
>> memory.
>> >
>> > Since the devices are connected via OpenCAPI, they are not enumerated
>> via ACPI. Instead, OpenCAPI links present as pseudo-PCI bridges, with
>> devices below them.
>> >
>> > This series introduces a driver that exposes the memory on these cards as
>> nvdimms, with each card getting it's own bus. This is somewhat complicated
>> by the fact that the cards do not have out of band persistent storage for
>> metadata, so 1 SECTION_SIZE's (see SPARSEMEM) worth of storage is carved
>> out of the top of the card storage to implement the ndctl_config_* calls.
>> 
>> Is it really tied to section-size? Can't that change based on the configured
>> page-size? It's not clear to me why that would be the choice, but I'll dig into
>> the implementation.
>> 
>
> I had tried using PAGE_SIZE, but ran into problems carving off just 1 page and handing it to the kernel, while leaving the rest as pmem. That was a while ago though, so maybe I should retry it.
>
>> > The driver is not responsible for configuring the NPU (NVLink Processing
>> Unit) BARs to map the LPC memory from the card into the system's physical
>> address space, instead, it requests this to be done via OPAL calls (typically
>> implemented by Skiboot).
>> 
>> Are OPAL calls similar to ACPI DSMs? I.e. methods for the OS to invoke
>> platform firmware services? What's Skiboot?
>> 
>
> Yes, OPAL is the interface to firmware for POWER. Skiboot is the open-source (and only) implementation of OPAL.

  https://github.com/open-power/skiboot

In particular the tokens for calls are defined here:

  https://github.com/open-power/skiboot/blob/master/include/opal-api.h#L220

And you can grep for the token to find the implementation:

  https://github.com/open-power/skiboot/blob/master/hw/npu2-opencapi.c#L2328


cheers