To give users the option to have the auto-behavior of memory to default
to SYSRAM, provide a switch. The default is still recommended to be DAX
in case of multiple devices being added to the system, but this provides
simpler systems a path to use the sysram controller for systems already
configured with auto-regions.
Signed-off-by: Gregory Price <gourry@gourry.net>
---
drivers/cxl/Kconfig | 32 ++++++++++++++++++++++++++++++
drivers/cxl/core/memctrl/memctrl.c | 2 ++
drivers/cxl/cxl.h | 2 +-
3 files changed, 35 insertions(+), 1 deletion(-)
diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
index 48b7314afdb8..5aed1524f8f1 100644
--- a/drivers/cxl/Kconfig
+++ b/drivers/cxl/Kconfig
@@ -211,6 +211,38 @@ config CXL_REGION
If unsure say 'y'
+choice
+ prompt "CXL Region Auto Control Mode"
+ depends on CXL_REGION
+ default CXL_REGION_CTRL_AUTO_DAX
+ help
+ Select the default controller for CXL regions when ctrl mode is
+ set to 'auto'. This determines how CXL memory regions are exposed
+ to the system when no explicit control mode is specified.
+
+config CXL_REGION_CTRL_AUTO_DAX
+ bool "DAX"
+ help
+ When a CXL region's control mode is 'auto', create a DAX region
+ controller. This allows fine-grained control over the memory region
+ through the DAX subsystem, and the region can later be converted to
+ System RAM via daxctl.
+
+ This is the default and recommended option for most use cases.
+
+config CXL_REGION_CTRL_AUTO_SYSRAM
+ bool "System RAM"
+ help
+ When a CXL region's control mode is 'auto', hotplug the region
+ directly as System RAM. This makes the CXL memory immediately
+ available to the kernel's memory allocator without requiring
+ additional userspace configuration.
+
+ Select this if you want CXL memory to be automatically available
+ as regular system memory.
+
+endchoice
+
config CXL_REGION_INVALIDATION_TEST
bool "CXL: Region Cache Management Bypass (TEST)"
depends on CXL_REGION
diff --git a/drivers/cxl/core/memctrl/memctrl.c b/drivers/cxl/core/memctrl/memctrl.c
index 1b661465bdeb..cb6c37f4c0ee 100644
--- a/drivers/cxl/core/memctrl/memctrl.c
+++ b/drivers/cxl/core/memctrl/memctrl.c
@@ -31,6 +31,8 @@ int cxl_enable_memctrl(struct cxl_region *cxlr)
p->res->start, p->res->end, cxlr,
is_system_ram) > 0)
return 0;
+ if (IS_ENABLED(CONFIG_CXL_REGION_CTRL_AUTO_SYSRAM))
+ return devm_cxl_add_sysram_region(cxlr);
return devm_cxl_add_dax_region(cxlr);
case CXL_MEMCTRL_DAX:
return devm_cxl_add_dax_region(cxlr);
diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
index c69d27a2e97d..1dae6fe4f70c 100644
--- a/drivers/cxl/cxl.h
+++ b/drivers/cxl/cxl.h
@@ -506,7 +506,7 @@ enum cxl_partition_mode {
/*
* Memory Controller modes:
* None - No controller selected
- * Auto - either BIOS-configured as SysRAM, or default to DAX
+ * Auto - Auto-select based on BIOS, boot, and build configs.
* DAX - creates a dax_region controller for the cxl_region
* SYSRAM - hotplugs the region directly as System RAM
* PMEM - persistent memory controller (nvdimm)
--
2.52.0On 1/12/2026 10:35 AM, Gregory Price wrote:
> To give users the option to have the auto-behavior of memory to default
> to SYSRAM, provide a switch. The default is still recommended to be DAX
> in case of multiple devices being added to the system, but this provides
> simpler systems a path to use the sysram controller for systems already
> configured with auto-regions.
>
> Signed-off-by: Gregory Price <gourry@gourry.net>
> ---
> drivers/cxl/Kconfig | 32 ++++++++++++++++++++++++++++++
> drivers/cxl/core/memctrl/memctrl.c | 2 ++
> drivers/cxl/cxl.h | 2 +-
> 3 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cxl/Kconfig b/drivers/cxl/Kconfig
> index 48b7314afdb8..5aed1524f8f1 100644
> --- a/drivers/cxl/Kconfig
> +++ b/drivers/cxl/Kconfig
> @@ -211,6 +211,38 @@ config CXL_REGION
>
> If unsure say 'y'
>
> +choice
> + prompt "CXL Region Auto Control Mode"
> + depends on CXL_REGION
> + default CXL_REGION_CTRL_AUTO_DAX
> + help
> + Select the default controller for CXL regions when ctrl mode is
> + set to 'auto'. This determines how CXL memory regions are exposed
> + to the system when no explicit control mode is specified.
> +
> +config CXL_REGION_CTRL_AUTO_DAX
This should probably be renamed to CXL_REGION_CTRL_DAX since only DAX is mentioned.
> + bool "DAX"
> + help
> + When a CXL region's control mode is 'auto', create a DAX region
> + controller. This allows fine-grained control over the memory region
> + through the DAX subsystem, and the region can later be converted to
> + System RAM via daxctl.
> +
> + This is the default and recommended option for most use cases.
If you remove the 'auto' mode earlier on, then you can just drop the first sentence here.
I'd also add a note about when a DAX region can be failed to be created (i.e. BIOS already
set up and onlined the memory).
> +
> +config CXL_REGION_CTRL_AUTO_SYSRAM
> + bool "System RAM"
> + help
> + When a CXL region's control mode is 'auto', hotplug the region
> + directly as System RAM. This makes the CXL memory immediately
> + available to the kernel's memory allocator without requiring
> + additional userspace configuration.
> +
> + Select this if you want CXL memory to be automatically available
> + as regular system memory.
> +
> +endchoice
> +
> config CXL_REGION_INVALIDATION_TEST
> bool "CXL: Region Cache Management Bypass (TEST)"
> depends on CXL_REGION
> diff --git a/drivers/cxl/core/memctrl/memctrl.c b/drivers/cxl/core/memctrl/memctrl.c
> index 1b661465bdeb..cb6c37f4c0ee 100644
> --- a/drivers/cxl/core/memctrl/memctrl.c
> +++ b/drivers/cxl/core/memctrl/memctrl.c
> @@ -31,6 +31,8 @@ int cxl_enable_memctrl(struct cxl_region *cxlr)
> p->res->start, p->res->end, cxlr,
> is_system_ram) > 0)
> return 0;
> + if (IS_ENABLED(CONFIG_CXL_REGION_CTRL_AUTO_SYSRAM))
> + return devm_cxl_add_sysram_region(cxlr);
> return devm_cxl_add_dax_region(cxlr);
> case CXL_MEMCTRL_DAX:
> return devm_cxl_add_dax_region(cxlr);
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index c69d27a2e97d..1dae6fe4f70c 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -506,7 +506,7 @@ enum cxl_partition_mode {
> /*
> * Memory Controller modes:
> * None - No controller selected
> - * Auto - either BIOS-configured as SysRAM, or default to DAX
> + * Auto - Auto-select based on BIOS, boot, and build configs.
> * DAX - creates a dax_region controller for the cxl_region
> * SYSRAM - hotplugs the region directly as System RAM
> * PMEM - persistent memory controller (nvdimm)
On Mon, Jan 12, 2026 at 03:10:55PM -0600, Cheatham, Benjamin wrote: > On 1/12/2026 10:35 AM, Gregory Price wrote: > > +choice > > + prompt "CXL Region Auto Control Mode" > > + depends on CXL_REGION > > + default CXL_REGION_CTRL_AUTO_DAX > > + help > > + Select the default controller for CXL regions when ctrl mode is > > + set to 'auto'. This determines how CXL memory regions are exposed > > + to the system when no explicit control mode is specified. > > + > > +config CXL_REGION_CTRL_AUTO_DAX > > This should probably be renamed to CXL_REGION_CTRL_DAX since only DAX is mentioned. > > > + bool "DAX" > > + help > > + When a CXL region's control mode is 'auto', create a DAX region > > + controller. This allows fine-grained control over the memory region > > + through the DAX subsystem, and the region can later be converted to > > + System RAM via daxctl. > > + > > + This is the default and recommended option for most use cases. > > If you remove the 'auto' mode earlier on, then you can just drop the first sentence here. > I'd also add a note about when a DAX region can be failed to be created (i.e. BIOS already > set up and onlined the memory). > I think I'm just going to drop this entirely, probably this was just too ambitious trying to create an easy transition from dax to sysram for auto regions. The reality is BIOS-configured decoders "is NOT the way" (TM). If BIOS configures it - it's DAX, otherwise the user gets a choice (or they can tear it down and rebuild). ~Gregory
Gregory Price wrote: [..] > > If you remove the 'auto' mode earlier on, then you can just drop the first sentence here. > > I'd also add a note about when a DAX region can be failed to be created (i.e. BIOS already > > set up and onlined the memory). > > > > I think I'm just going to drop this entirely, probably this was just too > ambitious trying to create an easy transition from dax to sysram for > auto regions. > > The reality is BIOS-configured decoders "is NOT the way" (TM). If BIOS > configures it - it's DAX, otherwise the user gets a choice (or they can > tear it down and rebuild). Is the plan here to "whither struct memory_block"? I can see value in starting the deprecation process given the problems Hannes points out and BIOS alignment causes massive numbers of those things to show up. If yes, then even if it is DAX the distro might still want the option to only allows for region-scoped "hotplug" rather than memory_block-scoped "online".
On Mon, Jan 12, 2026 at 08:31:56PM -0800, dan.j.williams@intel.com wrote: > Gregory Price wrote: > [..] > > > If you remove the 'auto' mode earlier on, then you can just drop the first sentence here. > > > I'd also add a note about when a DAX region can be failed to be created (i.e. BIOS already > > > set up and onlined the memory). > > > > > > > I think I'm just going to drop this entirely, probably this was just too > > ambitious trying to create an easy transition from dax to sysram for > > auto regions. > > > > The reality is BIOS-configured decoders "is NOT the way" (TM). If BIOS > > configures it - it's DAX, otherwise the user gets a choice (or they can > > tear it down and rebuild). > > Is the plan here to "whither struct memory_block"? I can see value in > starting the deprecation process given the problems Hannes points out > and BIOS alignment causes massive numbers of those things to show up. > > If yes, then even if it is DAX the distro might still want the option to > only allows for region-scoped "hotplug" rather than memory_block-scoped > "online". This was not an intent, but maybe? I'm not sure what the larger implications of this are - except that maybe poisoned regions of memory might take out larger chunks of hotplug memory. Other things may depend on memory block size in unexpected ways. I think maybe lets tuck that away until after we get region-scoped hotplug. Maybe it would look like this Step 1: Region-scoped hotplug that uses all the blocks Step 2: memory hotplug callbacks that disallow any hotplugger (except emergency hotplug?) from acting on individual blocks We already want this for online_movable, just defer a bit and make the guarantee stronger. Step 3: deprecate memory_block for something else? make memory_block variably sized with some base alignment? ~Gregory
© 2016 - 2026 Red Hat, Inc.