Skip to content
This repository has been archived by the owner on Nov 4, 2024. It is now read-only.

Latest commit

 

History

History
35 lines (20 loc) · 5 KB

README.md

File metadata and controls

35 lines (20 loc) · 5 KB

PROJECT NOT UNDER ACTIVE MANAGEMENT

This project will no longer be maintained by Intel.
Intel has ceased development and contributions including, but not limited to, maintenance, bug fixes, new releases, or updates, to this project.
Intel no longer accepts patches to this project.
If you have an ongoing need to use this project, are interested in independently developing it, or would like to maintain patches for the open source software community, please create your own fork of this project.

Persistent Memory Documentation

Introductory Materials

This USENIX ;login: article, published in the Summer of 2017, provides an overview of the persistent memory programming model and the related software work that has been taking place. It includes a very high-level description of programming with PMDK, although it refers to it by the old name, NVM Libraries. This article is actually a follow-on to an earlier article, published in the Summer 2013 issue of USENIX ;login:.

The Persistent Memory Summit 2018, held January 24th, 2018, provided a day full of informative talks and panels on persistent memory (slides and videos of the sesssions are available at above link).

The projects on this site, like PMDK, are product-neutral, meant to work on any product that provides the persistent memory programming model. One such product is Intel’s 3D XPoint. Intel has assembled a collection of persistent memory programming documentation, webinars, videos, and related materials on the Intel Developer Zone.

Dozens of companies have collaborated on a common persistent memory programming model in the SNIA NVM Programming Technical Workgroup (TWG). SNIA provides a persistent memory page on their web site with links to recent presentations, persistent memory standards and white papers, etc. The SNIA activity continues to be very active, working on areas like remote persistent memory and security. The original programming model specification put forward the basic idea that applications access persistent memory as memory-mapped files, a concept which has appeared as the DAX feature (Direct Access) on both Linux and Windows.

Standards

The SNIA NVM Programming Model standard describes the basic programming model used for persistent memory programming.

The ACPI Specification, starting with version 6.0, defines the NVDIMM Firmware Interface Table (NFIT) which is how the existence of persistent memory is communicated to operating systems. The specification also describes how NVDIMMs are partitioned into namespaces, methods for communicating with NVDIMMs, etc.

The UEFI Specification, covers other NVDIMM-related topics such as the Block Translation Table (BTT) which allows an NVDIMM to provide block device semantics.

Before the above two standards were developed, the NVDIMM Namespace Specification described the namespace and BTT mechanisms. The link to the outdated document is maintained here for reference.

Related Specifications

The NVDIMM Driver Writers Guide is targeted to driver writers for NVDIMMs that adhere to the NFIT tables in the Advanced Configuration and Power Interface (ACPI) V6.0 specification, the Device Specific Method (DSM) specification, and the NVDIMM Namespace Specification. This document specifically discusses the block window HW interface and persistent memory interface that Intel is proposing for NVDIMMs. A version of the document with change bars [pdf] from the previous version is also available.

The Intel Optane PMem DSM Interface, Version 3.0, describes the NVDIMM Device Specific Methods (_DSM) that pertain to Optane PMem modules. This document is provided as a reference for BIOS and OS driver writers supporting NVDIMMs and similar devices that appear in the ACPI NFIT table.

The Dirty Shutdown Handling guide describes the (hopefully rare) error case where flushes to persistent memory did not go as expected on power failure or system crash. The guide describes how this failure is detected, and how it is communicated to applications via the dirty shutdown count**.**