Re: [PATCH 0/6] dax/hmem, cxl: Coordinate Soft Reserved handling with CXL

["Koralahalli Channabasappa, Smita" <Smita.KoralahalliChannabasappa@amd.com>]

Hi Alison,

On 8/26/2025 4:21 PM, Alison Schofield wrote:
> On Fri, Aug 22, 2025 at 03:41:56AM +0000, Smita Koralahalli wrote:
>> This series aims to address long-standing conflicts between dax_hmem and
>> CXL when handling Soft Reserved memory ranges.
> 
> Hi Smita,
> 
> I was able to try this out today and it looks good. See one question
> about the !CXL_REGION case below.
> 
> Test case of a hot replace a dax region worked as expected. It appeared
> with no soft reserved and after tear down, the same region could be
> rebuilt in place.
> 
> Test case with CONFIG_CXL_REGION=N looks good too, as in DAX consumed
> the entire resource. Do we intend the Soft Reserved resource to remain
> like this:
> c080000000-17dbfffffff : CXL Window 0
>    c080000000-c47fffffff : Soft Reserved
>      c080000000-c47fffffff : dax2.0
>        c080000000-c47fffffff : System RAM (kmem)

Yes, that is how it currently looks. Maybe we should also add a log 
message to make it clear that this dax is coming from dax_hmem and not 
dax_cxl?

Another thought I had is that if we hand off fully to CXL even with 
regions disabled, we could avoid showing the Soft Reserved layer 
entirely (along with the kmem and devdax under it). The question is 
whether that approach would be preferable, since in that case the memory 
would end up left unclaimed/unavailable to Linux. Would be good to get 
your perspective on this.

https://lore.kernel.org/all/a2e900b0-1b89-4e88-a6d4-8c0e6de50f52@amd.com/

Thanks
Smita

> 
> These other issues noted previously did not re-appear:
> - kmem dax3.0: probe with driver kmem failed with error -16
> - resource: Unaddressable device  [ ] conflicts with []
> 
> -- Alison
> 
> snip
>