Re: [PATCH 8/9] cxl/core: Add dax_kmem_region and sysram_region drivers

Gregory Price
2026-02-02T17:41:35Z

On Mon, Feb 02, 2026 at 11:02:37AM -0600, Cheatham, Benjamin wrote:
> >
> > For auto-regions:
> > region_probe() eats it and you get the default behavior.
> >
> > For non-auto regions:
> > create_x_region generates an un-configured region and fails to probe
> > until the user commits it and probes it.
>
> I think this was the source of my misunderstanding. I was trying to understand how it
> works for auto regions when it's never meant to apply to them.
>
> Sorry if this is a stupid question, but what stops auto regions from binding to the
> sysram/dax region drivers? They all bind to region devices, so I assume there's something
> keeping them from binding before the core region driver gets a chance.
>

Auto regions explicitly use the dax_kmem path (all existing code,
unchanged)- which auto-plugs into dax/hotplug.

I do get what you're saying that everything binds on a region type,
I will look a little closer at this and see if there's something more
reasonable we can do.

I think i can update `region/bind` to use the sysram driver with
online_type=mhp_default_online_type

so you'd end up with effective the auto-region logic:

cxlcli create-region -m ram ... existing argument set
------
echo region0 > create_ram_region
/* program decoders */
echo region0 > region/bind
/*
* region_bind():
* 1) alloc sysram_region object
* 2) sysram_regionN->online_type=mhp_default_online_type()
* 3) add device to bus
* 4) device auto-probes all the way down to dax
* 5) dax auto-onlines with system default setting
*/
------

and Non-auto-region logic (approximation)

cxlcli creation-region -m ram --type sysram --online-type=movable
-----
echo region0 > create_ram_region
/* program decoders */
echo region0 > sysram/bind
echo online_movable > sysram_region0/online_type
echo sysram_region0 > dax_kmem/bind
-----

I want to retain the dax_kmem driver because there may be multiple users
other than sysram. For example, a compressed memory region wants to
utilize dax_kmem, but has its own complex policy (via N_MEMORY_PRIVATE)
so it doesn't want to abstract through sysram_region, but it does want
to abstract through dax_kmem.

weeeee "software defined memory" weeeee

~Gregory