The CXL driver currently hands policy management over to the DAX
subsystem for sysram regions.  This makes building policy around
entire regions clunky and at times difficult - for example, requiring
multiple actions to reliably offline and hot-unplug memory.

This series introduces a memory controller abstraction for CXL regions
and adds a "sysram" controller that directly hotplugs memory without
needing to route through DAX.  This simplifies the sysram use case
considerably.

This also prepares for future use cases which may require different
memory controller logic (such as private numa nodes).

We organize the controllers into core/memctrl/*_region.c files.

The series is organized as follows:

Patch 1 introduces the cxl_memctrl_mode enum and region->memctrl field,
allowing regions to be switched between different memory controllers.
The supported modes are NONE, AUTO, and DAX initially.  Auto-created
regions default to AUTO, while manually created regions default to NONE
(requiring explicit controller selection).

Patch 2 adds the sysram_region memory controller, which provides direct
memory hotplug without DAX intermediation.  New sysfs controls are
exposed under region/memctrl/:
  - hotplug:   trigger memory hotplug
  - hotunplug: offline and hotunplug memory
  - state:     online/online_normal/offline

Patch 3 refactors existing pmem memctrl logic out of region.c into the
new memctrl/pmem_region.c, simplifying controller selection in region
probe.

Patch 4 adds CONFIG_CXL_REGION_CTRL_AUTO_* options, allowing users to
configure auto-regions to default to SYSRAM instead of DAX for existing
simple system configurations (i.e. local memory expansion only).

Patch 5 adds CONFIG_CXL_REGION_SYSRAM_DEFAULT_* options to control the
default state of sysram blocks (OFFLINE, ONLINE/ZONE_MOVABLE, or
ONLINE_NORMAL/ZONE_NORMAL).  This provides an alternative to the global
MHP auto-online setting which may cause issues with other devices.

Online defaults to ZONE_MOVABLE to defend hot-unplug by default.
This is the opposite of memory blocks "online" and "online_movable".

Patch 6 adds a memory_notify callback that prevents memory blocks from
being onlined into ZONE_NORMAL when the controller state is set to
ZONE_MOVABLE.  This protects against administrators accidentally
breaking hot-unpluggability by writing "offline" then "online" to the
memory block sysfs.

Gregory Price (6):
  drivers/cxl: add cxl_memctrl_mode and region->memctrl
  cxl: add sysram_region memory controller
  cxl/core/region: move pmem memctrl logic into memctrl/pmem_region
  cxl: add CONFIG_CXL_REGION_CTRL_AUTO_* build config options
  cxl: add CXL_REGION_SYSRAM_DEFAULT_* build options
  cxl/sysram: disallow onlining in ZONE_NORMAL if state is movable only

 drivers/cxl/Kconfig                      |  72 ++++
 drivers/cxl/core/Makefile                |   1 +
 drivers/cxl/core/core.h                  |   5 +
 drivers/cxl/core/memctrl/Makefile        |   6 +
 drivers/cxl/core/memctrl/dax_region.c    |  79 ++++
 drivers/cxl/core/memctrl/memctrl.c       |  48 +++
 drivers/cxl/core/memctrl/pmem_region.c   | 191 +++++++++
 drivers/cxl/core/memctrl/sysram_region.c | 520 +++++++++++++++++++++++
 drivers/cxl/core/region.c                | 358 ++++------------
 drivers/cxl/cxl.h                        |  18 +
 10 files changed, 1013 insertions(+), 285 deletions(-)
 create mode 100644 drivers/cxl/core/memctrl/Makefile
 create mode 100644 drivers/cxl/core/memctrl/dax_region.c
 create mode 100644 drivers/cxl/core/memctrl/memctrl.c
 create mode 100644 drivers/cxl/core/memctrl/pmem_region.c
 create mode 100644 drivers/cxl/core/memctrl/sysram_region.c

-- 
2.52.0

On 12/01/26 11:35AM, Gregory Price wrote:
>The CXL driver currently hands policy management over to the DAX
>subsystem for sysram regions.  This makes building policy around
>entire regions clunky and at times difficult - for example, requiring
>multiple actions to reliably offline and hot-unplug memory.
>
>This series introduces a memory controller abstraction for CXL regions
>and adds a "sysram" controller that directly hotplugs memory without
>needing to route through DAX.  This simplifies the sysram use case
>considerably.
>
>This also prepares for future use cases which may require different
>memory controller logic (such as private numa nodes).
>
>We organize the controllers into core/memctrl/*_region.c files.
>
>The series is organized as follows:
>
>Patch 1 introduces the cxl_memctrl_mode enum and region->memctrl field,
>allowing regions to be switched between different memory controllers.
>The supported modes are NONE, AUTO, and DAX initially.  Auto-created
>regions default to AUTO, while manually created regions default to NONE
>(requiring explicit controller selection).
>
>Patch 2 adds the sysram_region memory controller, which provides direct
>memory hotplug without DAX intermediation.  New sysfs controls are
>exposed under region/memctrl/:
>  - hotplug:   trigger memory hotplug
>  - hotunplug: offline and hotunplug memory
>  - state:     online/online_normal/offline
>
>Patch 3 refactors existing pmem memctrl logic out of region.c into the
>new memctrl/pmem_region.c, simplifying controller selection in region
>probe.
>
>Patch 4 adds CONFIG_CXL_REGION_CTRL_AUTO_* options, allowing users to
>configure auto-regions to default to SYSRAM instead of DAX for existing
>simple system configurations (i.e. local memory expansion only).
>
>Patch 5 adds CONFIG_CXL_REGION_SYSRAM_DEFAULT_* options to control the
>default state of sysram blocks (OFFLINE, ONLINE/ZONE_MOVABLE, or
>ONLINE_NORMAL/ZONE_NORMAL).  This provides an alternative to the global
>MHP auto-online setting which may cause issues with other devices.
>
>Online defaults to ZONE_MOVABLE to defend hot-unplug by default.
>This is the opposite of memory blocks "online" and "online_movable".
>
>Patch 6 adds a memory_notify callback that prevents memory blocks from
>being onlined into ZONE_NORMAL when the controller state is set to
>ZONE_MOVABLE.  This protects against administrators accidentally
>breaking hot-unpluggability by writing "offline" then "online" to the
>memory block sysfs.
>
>Gregory Price (6):
>  drivers/cxl: add cxl_memctrl_mode and region->memctrl
>  cxl: add sysram_region memory controller
>  cxl/core/region: move pmem memctrl logic into memctrl/pmem_region
>  cxl: add CONFIG_CXL_REGION_CTRL_AUTO_* build config options
>  cxl: add CXL_REGION_SYSRAM_DEFAULT_* build options
>  cxl/sysram: disallow onlining in ZONE_NORMAL if state is movable only
>
> drivers/cxl/Kconfig                      |  72 ++++
> drivers/cxl/core/Makefile                |   1 +
> drivers/cxl/core/core.h                  |   5 +
> drivers/cxl/core/memctrl/Makefile        |   6 +
> drivers/cxl/core/memctrl/dax_region.c    |  79 ++++
> drivers/cxl/core/memctrl/memctrl.c       |  48 +++
> drivers/cxl/core/memctrl/pmem_region.c   | 191 +++++++++
> drivers/cxl/core/memctrl/sysram_region.c | 520 +++++++++++++++++++++++
> drivers/cxl/core/region.c                | 358 ++++------------
> drivers/cxl/cxl.h                        |  18 +
> 10 files changed, 1013 insertions(+), 285 deletions(-)
> create mode 100644 drivers/cxl/core/memctrl/Makefile
> create mode 100644 drivers/cxl/core/memctrl/dax_region.c
> create mode 100644 drivers/cxl/core/memctrl/memctrl.c
> create mode 100644 drivers/cxl/core/memctrl/pmem_region.c
> create mode 100644 drivers/cxl/core/memctrl/sysram_region.c
>
>-- 
>2.52.0
>

Hi Gregory,

I am facing compilation issue with this series using CONFIG_CXL_BUS=m
{{{
	  AR      drivers/built-in.a
	  AR      built-in.a
	  AR      vmlinux.a
	  LD      vmlinux.o
	  MODPOST Module.symvers
	ERROR: modpost: "device_offline" [drivers/cxl/core/cxl_core.ko] undefined!
	ERROR: modpost: "lock_device_hotplug_sysfs" [drivers/cxl/core/cxl_core.ko] undefined!
	ERROR: modpost: "unlock_device_hotplug" [drivers/cxl/core/cxl_core.ko] undefined!
	ERROR: modpost: "device_online" [drivers/cxl/core/cxl_core.ko] undefined!
	ERROR: modpost: "walk_memory_blocks" [drivers/cxl/core/cxl_core.ko] undefined!
	make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
	make[1]: *** [/mnt/ssd1/neeraj/dcd/cxl_env/cxl-linux-mainline/Makefile:2004: modpost] Error 2
	make: *** [Makefile:248: __sub-make] Error 2
}}}

Above routines are not EXPORT_SYMBOL_GPL(), thats why with
"CONFIG_CXL_BUS=m" its breaking.

After adding following EXPORT_SYMBOL_GPL() below their respective
routines. This issue is fixed.
{{{
	EXPORT_SYMBOL_GPL(unlock_device_hotplug);
	EXPORT_SYMBOL_GPL(lock_device_hotplug_sysfs);
	EXPORT_SYMBOL_GPL(device_offline);
	EXPORT_SYMBOL_GPL(device_online);
	EXPORT_SYMBOL_GPL(walk_memory_blocks);
}}}

Can you please have a look?


Regards,
Neeraj

On Tue, Jan 13, 2026 at 03:07:49PM +0530, Neeraj Kumar wrote:
> Hi Gregory,
> 
> I am facing compilation issue with this series using CONFIG_CXL_BUS=m
> {{{
> 	  AR      drivers/built-in.a
> 	  AR      built-in.a
> 	  AR      vmlinux.a
> 	  LD      vmlinux.o
> 	  MODPOST Module.symvers
> 	ERROR: modpost: "device_offline" [drivers/cxl/core/cxl_core.ko] undefined!
> 	ERROR: modpost: "lock_device_hotplug_sysfs" [drivers/cxl/core/cxl_core.ko] undefined!
> 	ERROR: modpost: "unlock_device_hotplug" [drivers/cxl/core/cxl_core.ko] undefined!
> 	ERROR: modpost: "device_online" [drivers/cxl/core/cxl_core.ko] undefined!
> 	ERROR: modpost: "walk_memory_blocks" [drivers/cxl/core/cxl_core.ko] undefined!
> 	make[2]: *** [scripts/Makefile.modpost:147: Module.symvers] Error 1
> 	make[1]: *** [/mnt/ssd1/neeraj/dcd/cxl_env/cxl-linux-mainline/Makefile:2004: modpost] Error 2
> 	make: *** [Makefile:248: __sub-make] Error 2
> }}}
> 
> Above routines are not EXPORT_SYMBOL_GPL(), thats why with
> "CONFIG_CXL_BUS=m" its breaking.
> 
> After adding following EXPORT_SYMBOL_GPL() below their respective
> routines. This issue is fixed.
> {{{
> 	EXPORT_SYMBOL_GPL(unlock_device_hotplug);
> 	EXPORT_SYMBOL_GPL(lock_device_hotplug_sysfs);
> 	EXPORT_SYMBOL_GPL(device_offline);
> 	EXPORT_SYMBOL_GPL(device_online);
> 	EXPORT_SYMBOL_GPL(walk_memory_blocks);
> }}}
> 
> Can you please have a look?
>

Much appreciated, will fixup!

~Gregory

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.


Thank you!


On 1/12/26 16:35, Gregory Price wrote:
> The CXL driver currently hands policy management over to the DAX
> subsystem for sysram regions.  This makes building policy around
> entire regions clunky and at times difficult - for example, requiring
> multiple actions to reliably offline and hot-unplug memory.
>
> This series introduces a memory controller abstraction for CXL regions
> and adds a "sysram" controller that directly hotplugs memory without
> needing to route through DAX.  This simplifies the sysram use case
> considerably.
>
> This also prepares for future use cases which may require different
> memory controller logic (such as private numa nodes).
>
> We organize the controllers into core/memctrl/*_region.c files.
>
> The series is organized as follows:
>
> Patch 1 introduces the cxl_memctrl_mode enum and region->memctrl field,
> allowing regions to be switched between different memory controllers.
> The supported modes are NONE, AUTO, and DAX initially.  Auto-created
> regions default to AUTO, while manually created regions default to NONE
> (requiring explicit controller selection).
>
> Patch 2 adds the sysram_region memory controller, which provides direct
> memory hotplug without DAX intermediation.  New sysfs controls are
> exposed under region/memctrl/:
>    - hotplug:   trigger memory hotplug
>    - hotunplug: offline and hotunplug memory
>    - state:     online/online_normal/offline
>
> Patch 3 refactors existing pmem memctrl logic out of region.c into the
> new memctrl/pmem_region.c, simplifying controller selection in region
> probe.
>
> Patch 4 adds CONFIG_CXL_REGION_CTRL_AUTO_* options, allowing users to
> configure auto-regions to default to SYSRAM instead of DAX for existing
> simple system configurations (i.e. local memory expansion only).
>
> Patch 5 adds CONFIG_CXL_REGION_SYSRAM_DEFAULT_* options to control the
> default state of sysram blocks (OFFLINE, ONLINE/ZONE_MOVABLE, or
> ONLINE_NORMAL/ZONE_NORMAL).  This provides an alternative to the global
> MHP auto-online setting which may cause issues with other devices.
>
> Online defaults to ZONE_MOVABLE to defend hot-unplug by default.
> This is the opposite of memory blocks "online" and "online_movable".
>
> Patch 6 adds a memory_notify callback that prevents memory blocks from
> being onlined into ZONE_NORMAL when the controller state is set to
> ZONE_MOVABLE.  This protects against administrators accidentally
> breaking hot-unpluggability by writing "offline" then "online" to the
> memory block sysfs.
>
> Gregory Price (6):
>    drivers/cxl: add cxl_memctrl_mode and region->memctrl
>    cxl: add sysram_region memory controller
>    cxl/core/region: move pmem memctrl logic into memctrl/pmem_region
>    cxl: add CONFIG_CXL_REGION_CTRL_AUTO_* build config options
>    cxl: add CXL_REGION_SYSRAM_DEFAULT_* build options
>    cxl/sysram: disallow onlining in ZONE_NORMAL if state is movable only
>
>   drivers/cxl/Kconfig                      |  72 ++++
>   drivers/cxl/core/Makefile                |   1 +
>   drivers/cxl/core/core.h                  |   5 +
>   drivers/cxl/core/memctrl/Makefile        |   6 +
>   drivers/cxl/core/memctrl/dax_region.c    |  79 ++++
>   drivers/cxl/core/memctrl/memctrl.c       |  48 +++
>   drivers/cxl/core/memctrl/pmem_region.c   | 191 +++++++++
>   drivers/cxl/core/memctrl/sysram_region.c | 520 +++++++++++++++++++++++
>   drivers/cxl/core/region.c                | 358 ++++------------
>   drivers/cxl/cxl.h                        |  18 +
>   10 files changed, 1013 insertions(+), 285 deletions(-)
>   create mode 100644 drivers/cxl/core/memctrl/Makefile
>   create mode 100644 drivers/cxl/core/memctrl/dax_region.c
>   create mode 100644 drivers/cxl/core/memctrl/memctrl.c
>   create mode 100644 drivers/cxl/core/memctrl/pmem_region.c
>   create mode 100644 drivers/cxl/core/memctrl/sysram_region.c
>

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