Messages in this thread | | | From | Michael Ellerman <> | Subject | RE: [PATCH v4 00/25] Add support for OpenCAPI Persistent Memory devices | Date | Thu, 02 Apr 2020 14:42:29 +1100 |
| |
"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
| |