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] [thread-next>] [day] [month] [year] [list]

Message-ID: <aNus2chNlLGmEiOg@kernel.org>
Date: Tue, 30 Sep 2025 12:11:37 +0200
From: Mike Rapoport <rppt@...nel.org>
To: dan.j.williams@...el.com
Cc: Dave Jiang <dave.jiang@...el.com>, Ira Weiny <ira.weiny@...el.com>,
	Vishal Verma <vishal.l.verma@...el.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

On Tue, Sep 23, 2025 at 06:08:24PM -0700, dan.j.williams@...el.com wrote:
> 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.
> > 
> > The DIMMs support label space management on the "device" and provide a
> > flexible way to access RAM using fsdax and devdax.
> 
> Hi Mike, I like this. Some questions below:
> 
> > +static struct platform_driver ramdax_driver = {
> > +	.probe = ramdax_probe,
> > +	.remove = ramdax_remove,
> > +	.driver = {
> > +		.name = "e820_pmem",
> > +		.of_match_table = of_match_ptr(ramdax_of_matches),
> 
> So this driver collides with both e820_pmem and of_pmem, but I think it
> would be useful to have both options (with/without labels) available and
> not require disabling both those other drivers at compile time.
> 
> 'struct pci_device_id' has this useful "override_only" flag to require
> that the only driver that attaches is one that is explicitly requested
> (see pci_match_device()).
> 
> Now, admittedly platform_match() is a bit more complicated in that it
> matches 3 different platform device id types, but I think the ability to
> opt-in to this turns this from a "cloud-host-provider-only" config
> option to something distro kernels can enable by default.

It looks like /sys/bus/platform/devices/e820_pmem/driver_override does the
trick.

I'll make the driver to use "ramdax" as the name and rely on
driver_override for binding it to a device.

-- 
Sincerely yours,
Mike.