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

From: Michael Ellerman <mpe@ellerman.id.au>
To: Alastair D'Silva <alastair@d-silva.org>,
	'Dan Williams' <dan.j.williams@intel.com>
Cc: "'Aneesh Kumar K . V'" <aneesh.kumar@linux.ibm.com>,
	"'Benjamin Herrenschmidt'" <benh@kernel.crashing.org>,
	"'Paul Mackerras'" <paulus@samba.org>,
	"'Frederic Barrat'" <fbarrat@linux.ibm.com>,
	"'Andrew Donnellan'" <ajd@linux.ibm.com>,
	"'Arnd Bergmann'" <arnd@arndb.de>,
	"'Greg Kroah-Hartman'" <gregkh@linuxfoundation.org>,
	"'Andrew Morton'" <akpm@linux-foundation.org>,
	"'Mauro Carvalho Chehab'" <mchehab+samsung@kernel.org>,
	"'David S. Miller'" <davem@davemloft.net>,
	"'Rob Herring'" <robh@kernel.org>,
	"'Anton Blanchard'" <anton@ozlabs.org>,
	"'Krzysztof Kozlowski'" <krzk@kernel.org>,
	"'Mahesh Salgaonkar'" <mahesh@linux.vnet.ibm.com>,
	"'Madhavan Srinivasan'" <maddy@linux.vnet.ibm.com>,
	"'Cédric Le Goater'" <clg@kaod.org>,
	"'Anju T Sudhakar'" <anju@linux.vnet.ibm.com>,
	"'Hari Bathini'" <hbathini@linux.ibm.com>,
	"'Thomas Gleixner'" <tglx@linutronix.de>,
	"'Greg Kurz'" <groug@kaod.org>,
	"'Nicholas Piggin'" <npiggin@gmail.com>,
	"'Masahiro Yamada'" <yamada.masahiro@socionext.com>,
	"'Alexey Kardashevskiy'" <aik@ozlab>
Subject: RE: [PATCH v4 00/25] Add support for OpenCAPI Persistent Memory devices
Date: Thu, 02 Apr 2020 14:42:29 +1100	[thread overview]
Message-ID: <87imiituxm.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <2d6901d60877$16aa7a90$43ff6fb0$@d-silva.org>

"Alastair D'Silva" <alastair@d-silva.org> writes:
>> -----Original Message-----
>> From: Dan Williams <dan.j.williams@intel.com>
>> 
>> On Sun, Mar 29, 2020 at 10:23 PM Alastair D'Silva <alastair@d-silva.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
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org