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-8c0e6de50...@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
