linux-kernel - Re: [PATCH 1/1] nvdimm: allow exposing RAM carveouts as NVDIMM DIMM 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] [day] [month] [year] [list]

Message-ID: <aLFdVX4eXrDnDD25@kernel.org>
Date: Fri, 29 Aug 2025 10:57:09 +0300
From: Mike Rapoport <rppt@...nel.org>
To: Ira Weiny <ira.weiny@...el.com>
Cc: Dan Williams <dan.j.williams@...el.com>,
	Dave Jiang <dave.jiang@...el.com>,
	Vishal Verma <vishal.l.verma@...el.com>,
	Michal Clapinski <mclapinski@...gle.com>, jane.chu@...cle.com,
	Pasha Tatashin <pasha.tatashin@...een.com>,
	Tyler Hicks <code@...icks.com>, linux-kernel@...r.kernel.org,
	nvdimm@...ts.linux.dev
Subject: Re: [PATCH 1/1] nvdimm: allow exposing RAM carveouts as NVDIMM DIMM
 devices

Hi Ira,

On Thu, Aug 28, 2025 at 07:47:31PM -0500, Ira Weiny wrote:
> + Michal
> 
> Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)" <rppt@...nel.org>
> > 
> > There are use cases, for example virtual machine hosts, that create
> > "persistent" memory regions using memmap= option on x86 or dummy
> > pmem-region device tree nodes on DT based systems.
> > 
> > Both these options are inflexible because they create static regions and
> > the layout of the "persistent" memory cannot be adjusted without reboot
> > and sometimes they even require firmware update.
> > 
> > Add a ramdax driver that allows creation of DIMM devices on top of
> > E820_TYPE_PRAM regions and devicetree pmem-region nodes.
> 
> While I recognize this driver and the e820 driver are mutually
> exclusive[1][2].  I do wonder if the use cases are the same?

They are mutually exclusive in the sense that they cannot be loaded
together so I had this in Kconfig in RFC posting

config RAMDAX
	tristate "Support persistent memory interfaces on RAM carveouts"
	depends on OF || (X86 && X86_PMEM_LEGACY=n)

(somehow my rebase lost Makefile and Kconfig changes :( )

As Pasha said in the other thread [1] the use-cases are different. My goal
is to achieve flexibility in managing carved out "PMEM" regions and
Michal's patches aim to optimize boot time by autoconfiguring multiple PMEM
regions in the kernel without upcalls to ndctl.
 
> From a high level I don't like the idea of adding kernel parameters.  So
> if this could solve Michal's problem I'm inclined to go this direction.

I think it could help with optimizing the reboot times. On the first boot
the PMEM is partitioned using ndctl and then the partitioning remains there
so that on subsequent reboots kernel recreates dax devices without upcalls
to userspace.

[1] https://lore.kernel.org/all/CA+CK2bAPJR00j3eFZtF7WgvgXuqmmOtqjc8xO70bGyQUSKTKGg@mail.gmail.com/

-- 
Sincerely yours,
Mike.