linux-kernel - Re: [PATCH 0/6] CXL: Introduce memory controller abstraction and sysram controller

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: <aWk4QX_zbyA3sDMT@gourry-fedora-PF4VCD3F>
Date: Thu, 15 Jan 2026 13:56:01 -0500
From: Gregory Price <gourry@...rry.net>
To: Alejandro Lucero Palau <alucerop@....com>
Cc: linux-cxl@...r.kernel.org, linux-kernel@...r.kernel.org,
	kernel-team@...a.com, dave@...olabs.net,
	jonathan.cameron@...wei.com, dave.jiang@...el.com,
	alison.schofield@...el.com, vishal.l.verma@...el.com,
	ira.weiny@...el.com, dan.j.williams@...el.com
Subject: Re: [PATCH 0/6] CXL: Introduce memory controller abstraction and
 sysram controller

On Thu, Jan 15, 2026 at 06:43:08PM +0000, Alejandro Lucero Palau wrote:
> Hi Gregory,
> 
> 
> I was concerned with how this could affect Type2 but I think there is no
> issue at all, but I prefer to ask specifically about it.
> 
> 
> Type2 can obtain an auto region if BIOS enabled/configured the HDMs, or it
> can create one on purpose if not. Type2 patchset does not allow to create a
> dax region when region probing and it will be the same type2 check
> precluding call to enabling the sysram controller.
> 
> 
> However, I can see the region will have default sysfs files for setting the
> controller. I think even with such a change there is no way for enabling the
> controller from the type2 region probing, so I guess it is safe, but I would
> prefer to not allow a Type2 region setting a controller at all.
> 
> 
> I like the approach for solving the problem pointed out, and I think
> something similar or a controller extension for type2 could be needed in the
> future, but maybe adding more flexibility for theoretical per type2 driver
> memory-handling uniqueness.
> 
> 

(pre-note: we changed the verbiage from controller to driver)

I think Type2 devices (and some special memory devices) are exactly
the use case that drives formalizing region-drivers.

Some Type2 devices might just register a normal memory region.

Some Type2 devices might want a dax device.

Some Type2 devices might want a "private memory" region (private node).

Some Type2 devices might have a completely different usage pattern.

Maybe we might want a control that limits which drivers a given device
can use (limiting switch-ability), and let devices inform the core
region driver of that in some way.

The sysfs toggle is a pressure-valve for devices that might be configurable
in multiple ways.  Maybe it won't actually be needed, but at least for
"Regular Memory" devices i can see us having dax and sysram drivers at a
minimum.

The base sysram driver may even be the basis for a dcd_sysram driver.
After all it's just a sysram driver w/ add/remove extent functions :]

~Gregory