Re: cxl/region.c improvements and DAX/Hotplug plumbing

[Gregory Price]

On Wed, Mar 18, 2026 at 09:53:05AM +0100, David Hildenbrand (Arm) wrote:
> > and would change the sysfs pattern to
> > 	echo regionN > cxl/decoder0.0/create_ram_region
> > 	echo regionN > cxl/drivers/sysram_region/bind
> > 	echo online_movable > cxl/devices/dax_regionN/hotplug
> >         echo dax_regionN > cxl/drivers/dax_region/bind
> > 
> > and gives the user a chance to configure a policy before the region
> > is pumped all the way through to the endpoint dax driver.
> 
> Would that still be backwards-compatible?
> 

I've since squared this away with the CXL groups, the answer is a
different probe path and leaving the auto-probe logic alone.

I still need to re-submit the /hotplug extensions here as an improvement
because its useful - but i've cleaned it up considerably to avoid the
cross-subsystem nonsense.

> > 
> > For most use-cases yes.  For something like FAMFS (distributed shared
> > memory), one system onlining a block as kmem could be potentially
> > destructive to an entirely separate physical server.
> 
> Right. But shouldn't we fail this already at the add_memory() stage?
> Sounds like during onlining is a bit too late. Conceptually, the hotplug
> as sysram was already wrong for famfs, or am I wrong?
>

Mostly this describes the baggage associated with auto-hotplug path for
all CXL memory, and the fact that we only have a global-scope auto MHP
tag.  I've come around to better solutions to this problem.

Thanks for the read n_n

~Gregory