All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Dan Williams <dan.j.williams@intel.com>,
	Dave Jiang <dave.jiang@intel.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Vishal Verma <vishal.l.verma@intel.com>
Cc: jane.chu@oracle.com, "Michał Cłapiński" <mclapinski@google.com>,
	"Mike Rapoport" <rppt@kernel.org>,
	"Pasha Tatashin" <pasha.tatashin@soleen.com>,
	"Tyler Hicks" <code@tyhicks.com>,
	linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev
Subject: [PATCH v2 0/1] nvdimm: allow exposing RAM as libnvdimm DIMMs
Date: Wed, 15 Oct 2025 11:00:19 +0300	[thread overview]
Message-ID: <20251015080020.3018581-1-rppt@kernel.org> (raw)

From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>

Hi,

It's not uncommon that libnvdimm/dax/ndctl are used with normal volatile
memory for a whole bunch of $reasons.

Probably the most common usecase is to back VMs memory with fsdax/devdax,
but there are others as well when there's a requirement to manage memory
separately from the kernel.

The existing mechanisms to expose normal ram as "persistent", such as
memmap=x!y on x86 or dummy pmem-region device tree nodes on DT systems lack
flexibility to dynamically partition a single region without rebooting the
system and sometimes even updating the system firmware. Also, to create
several DAX devices with different properties it's necessary to repeat
the memmap= command line option or add several pmem-region nodes to the
DT.

I propose a new ramdax driver that will create a DIMM device on
E820_TYPE_PRAM/pmem-region and that will allow partitioning that device
dynamically. The label area is kept in the end of that region and managed
by the driver.

v2 changes:
* Change the way driver is bound to a device, following Dan's
  suggestion. Instead of forcing mutual exclusion of ramdax and
  nr_e820/of-pmem at build time, rely on 'driver_override' attribute to
  allow binding ramdax driver to e820_pmem/pmem-region devices.
* Fix build warning reported by kbuild

v1: https://lore.kernel.org/all/20250826080430.1952982-1-rppt@kernel.org
* fix offset calculations in ramdax_{get,set}_config_data
* use a magic constant instead of a random number as nd_set->cookie*

RFC: https://lore.kernel.org/all/20250612083153.48624-1-rppt@kernel.org

Mike Rapoport (Microsoft) (1):
  nvdimm: allow exposing RAM carveouts as NVDIMM DIMM devices

 drivers/nvdimm/Kconfig  |  17 +++
 drivers/nvdimm/Makefile |   1 +
 drivers/nvdimm/ramdax.c | 272 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 290 insertions(+)
 create mode 100644 drivers/nvdimm/ramdax.c


base-commit: 3a8660878839faadb4f1a6dd72c3179c1df56787
--
2.50.1

             reply	other threads:[~2025-10-15  8:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-15  8:00 Mike Rapoport [this message]
2025-10-15  8:00 ` [PATCH v2 1/1] nvdimm: allow exposing RAM carveouts as NVDIMM DIMM devices Mike Rapoport
2025-10-18  0:08   ` dan.j.williams
2025-10-22 14:47     ` Mike Rapoport
2025-10-22 23:29       ` dan.j.williams
2025-10-23  7:39         ` Mike Rapoport

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20251015080020.3018581-1-rppt@kernel.org \
    --to=rppt@kernel.org \
    --cc=code@tyhicks.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.jiang@intel.com \
    --cc=ira.weiny@intel.com \
    --cc=jane.chu@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mclapinski@google.com \
    --cc=nvdimm@lists.linux.dev \
    --cc=pasha.tatashin@soleen.com \
    --cc=vishal.l.verma@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.