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: <edb6cd44-76df-4d68-8df8-2e7f3a7db73b@amd.com>
Date: Thu, 15 Jan 2026 18:43:08 +0000
From: Alejandro Lucero Palau <alucerop@....com>
To: Gregory Price <gourry@...rry.net>, linux-cxl@...r.kernel.org
Cc: 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

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
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ