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

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

Hi Alison,

On 10/10/2025 1:49 PM, Alison Schofield wrote:
> On Mon, Oct 06, 2025 at 06:16:24PM -0700, Alison Schofield wrote:
>> On Tue, Sep 30, 2025 at 04:47:52AM +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,
>>
>> Thanks for the updates Smita!
>>
>> About those "long-standing conflicts": In the next rev, can you resurrect,
>> or recreate the issues list that this set is addressing. It's been a
>> long and winding road with several handoffs (me included) and it'll help
>> keep the focus.
>>
>> Hotplug works :)  Auto region comes up, we tear it down and can recreate it,
>> in place, because the soft reserved resource is gone (no longer occupying
>> the CXL Window and causing recreate to fail.)
>>
>> !CONFIG_CXL_REGION works :) All resources go directly to DAX.
>>
>> The scenario that is failing is handoff to DAX after region assembly
>> failure. (Dan reminded me to check that today.) That is mostly related
>> to Patch4, so I'll respond there.
>>
>> --Alison
> 
> Hi Smita -
> 
> (after off-list chat w Smita about what is and is not included)
> 
> This CXL failover to DAX case is not implemented. In my response in Patch 4,
> I cobbled something together that made it work in one test case. But to be
> clear, there was some trickery in the CXL region driver to even do that.
> 
> One path forward is to update this set restating the issues it addresses, and
> remove any code and comments that are tied to failing over to DAX after a
> region assembly failure.
> 
> That leaves the issue Dan raised, "shutdown CXL in favor of vanilla DAX devices
> as an emergency fallback for platform configuration quirks and bugs"[1], for a
> future patch.
> 
> -- Alison
> 
> [1] The failover to DAX was last described in response to v5 of the 'prior' patchset.
> https://lore.kernel.org/linux-cxl/20250715180407.47426-1-Smita.KoralahalliChannabasappa@amd.com/
> https://lore.kernel.org/linux-cxl/687ffcc0ee1c8_137e6b100ed@dwillia2-xfh.jf.intel.com.notmuch/
> https://lore.kernel.org/linux-cxl/68808fb4e4cbf_137e6b100cc@dwillia2-xfh.jf.intel.com.notmuch/

[+cc Nathan, Terry]

 From the AMD side, our primary concern in this series is CXL hotplug. 
With the patches as is, the hotplug flows are working for us: region 
comes up, we can tear it down, and recreate it in place because the soft 
reserved window is released.

On our systems I consistently see wait_for_device_probe() block until 
region assembly has completed so I don’t currently have evidence of a 
sequencing hole there on AMD platforms.

Once CXL windows are discovered, would it be acceptable for dax_hmem to 
simply ignore soft reserved ranges inside those windows, assuming CXL 
will own and manage them? That aligns with Dan’s guidance about letting 
CXL win those ranges when present.
https://lore.kernel.org/all/687fef9ec0dd9_137e6b100c8@dwillia2-xfh.jf.intel.com.notmuch/

If that approach sounds right, I can reword the commit descriptions in 
patches 4/5 and 5/5 to drop the parts about region assembly failures and 
remove the REGISTER enum.

And then leave the “shutdown CXL in favor of vanilla DAX as an emergency 
fallback for platform configuration quirks and bugs” to a future, 
dedicated patch.

Thanks
Smita

> 
>>
>>