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

[David Hildenbrand (Arm)]

On 3/19/26 16:14, Gregory Price wrote:
> 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.

I'm curious :)

> 
> Thanks for the read n_n

Sorry again for the late reply.

-- 
Cheers,

David