From: "Koralahalli Channabasappa, Smita" <skoralah@amd.com>
To: "Zhijian Li (Fujitsu)" <lizhijian@fujitsu.com>,
Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>,
"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"nvdimm@lists.linux.dev" <nvdimm@lists.linux.dev>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Cc: Davidlohr Bueso <dave@stgolabs.net>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
Dave Jiang <dave.jiang@intel.com>,
Alison Schofield <alison.schofield@intel.com>,
Vishal Verma <vishal.l.verma@intel.com>,
Ira Weiny <ira.weiny@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Matthew Wilcox <willy@infradead.org>, Jan Kara <jack@suse.cz>,
"Rafael J . Wysocki" <rafael@kernel.org>,
Len Brown <len.brown@intel.com>, Pavel Machek <pavel@kernel.org>,
Li Ming <ming.li@zohomail.com>,
Jeff Johnson <jeff.johnson@oss.qualcomm.com>,
Ying Huang <huang.ying.caritas@gmail.com>,
"Xingtao Yao (Fujitsu)" <yaoxt.fnst@fujitsu.com>,
Peter Zijlstra <peterz@infradead.org>,
Greg KH <gregkh@linuxfoundation.org>,
Nathan Fontenot <nathan.fontenot@amd.com>,
Terry Bowman <terry.bowman@amd.com>,
Robert Richter <rrichter@amd.com>,
Benjamin Cheatham <benjamin.cheatham@amd.com>,
PradeepVineshReddy Kodamati <PradeepVineshReddy.Kodamati@amd.com>
Subject: Re: [RFC PATCH 6/6] cxl/region, dax/hmem: Guard CXL DAX region creation and tighten HMEM deps
Date: Mon, 29 Sep 2025 21:06:47 -0700 [thread overview]
Message-ID: <652a4391-4825-46bf-9f64-52e0ef751dff@amd.com> (raw)
In-Reply-To: <2397ebb5-ae63-402e-bc23-339c74be9210@fujitsu.com>
On 8/31/2025 11:21 PM, Zhijian Li (Fujitsu) wrote:
>
>
> On 22/08/2025 11:42, Smita Koralahalli wrote:
>> Prevent cxl_region_probe() from unconditionally calling into
>> devm_cxl_add_dax_region() when the DEV_DAX_CXL driver is not enabled.
>> Wrap the call with IS_ENABLED(CONFIG_DEV_DAX_CXL) so region probe skips
>> DAX setup cleanly if no consumer is present.
>
> A question came to mind:
>
> Why is the case of `CXL_REGION && !DEV_DAX_CXL` necessary? It appears to fall back to the hmem driver in that scenario.
> If so, could we instead simplify it as follows?
>
> --- a/drivers/cxl/Kconfig
> +++ b/drivers/cxl/Kconfig
> @@ -200,6 +200,7 @@ config CXL_REGION
> depends on SPARSEMEM
> select MEMREGION
> select GET_FREE_REGION
> + select DEV_DAX_CXL
>
I’m not entirely sure about the full implications of disabling
CXL_REGION when DEV_DAX_CXL is disabled.
The primary intent of this patch was to address the scenario where
DEV_DAX_HMEM=y and CXL=m, which results in DEV_DAX_CXL being disabled.
In that configuration, ownership of the soft-reserved ranges incorrectly
falls back to hmem instead of being managed by CXL. This leads to
misleading output in /proc/iomem, as I illustrated earlier.
That said, as you pointed out, dax_hmem is not exclusive to CXL, so I
will drop this patch in v2. The next revision will therefore not cover
the case of DEV_DAX_HMEM=y and CXL=m. I would appreciate input on how
best to handle this scenario efficiently.
Thanks
Smita
>>
>> In parallel, update DEV_DAX_HMEM’s Kconfig to depend on
>> !CXL_BUS || (CXL_ACPI && CXL_PCI) || m. This ensures:
>>
>> Built-in (y) HMEM is allowed when CXL is disabled, or when the full
>> CXL discovery stack is built-in. Module (m) HMEM remains always possible.
>
> Hmm,IIUC, `dax_hmem` isn't exclusively designed for CXL. It could support other special memory types (e.g., HBM).
>
> Thanks
> Zhijian
>
>
>
>>
>> Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
>> ---
>> I did not want to override Dan’s original approach, so I am posting this
>> as an RFC.
>>
>> This patch addresses a corner case when applied on top of Patches 1–5.
>>
>> When DEV_DAX_HMEM=y and CXL=m, the DEV_DAX_CXL option ends up disabled.
>> In that configuration, with Patches 1–5 applied, ownership of the Soft
>> Reserved ranges falls back to dax_hmem. As a result, /proc/iomem looks
>> like this:
>>
>> 850000000-284fffffff : CXL Window 0
>> 850000000-284fffffff : region3
>> 850000000-284fffffff : Soft Reserved
>> 850000000-284fffffff : dax0.0
>> 850000000-284fffffff : System RAM (kmem)
>> 2850000000-484fffffff : CXL Window 1
>> 2850000000-484fffffff : region4
>> 2850000000-484fffffff : Soft Reserved
>> 2850000000-484fffffff : dax1.0
>> 2850000000-484fffffff : System RAM (kmem)
>> 4850000000-684fffffff : CXL Window 2
>> 4850000000-684fffffff : region5
>> 4850000000-684fffffff : Soft Reserved
>> 4850000000-684fffffff : dax2.0
>> 4850000000-684fffffff : System RAM (kmem)
>>
>> In this case the dax devices are created by dax_hmem, not by dax_cxl.
>> Consequently, a "cxl disable-region <regionx>" operation does not
>> unregister these devices. In addition, the dmesg output can be misleading
>> to users, since it looks like the CXL region driver created the devdax
>> devices:
>>
>> devm_cxl_add_region: cxl_acpi ACPI0017:00: decoder0.2: created region5
>> ..
>> ..
>>
>> This patch addresses those situations. I am not entirely sure how clean
>> the approach of using “|| m” is, so I am sending it as RFC for feedback.
>> ---
>> drivers/cxl/core/region.c | 4 +++-
>> drivers/dax/Kconfig | 1 +
>> 2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
>> index 71cc42d05248..6a2c21e55dbc 100644
>> --- a/drivers/cxl/core/region.c
>> +++ b/drivers/cxl/core/region.c
>> @@ -3617,7 +3617,9 @@ static int cxl_region_probe(struct device *dev)
>> p->res->start, p->res->end, cxlr,
>> is_system_ram) > 0)
>> return 0;
>> - return devm_cxl_add_dax_region(cxlr);
>> + if (IS_ENABLED(CONFIG_DEV_DAX_CXL))
>> + return devm_cxl_add_dax_region(cxlr);
>> + return 0;
>> default:
>> dev_dbg(&cxlr->dev, "unsupported region mode: %d\n",
>> cxlr->mode);
>> diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
>> index 3683bb3f2311..fd12cca91c78 100644
>> --- a/drivers/dax/Kconfig
>> +++ b/drivers/dax/Kconfig
>> @@ -30,6 +30,7 @@ config DEV_DAX_PMEM
>> config DEV_DAX_HMEM
>> tristate "HMEM DAX: direct access to 'specific purpose' memory"
>> depends on EFI_SOFT_RESERVE
>> + depends on !CXL_BUS || (CXL_ACPI && CXL_PCI) || m
>> select NUMA_KEEP_MEMINFO if NUMA_MEMBLKS
>> default DEV_DAX
>> help
next prev parent reply other threads:[~2025-09-30 4:06 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-22 3:41 [PATCH 0/6] dax/hmem, cxl: Coordinate Soft Reserved handling with CXL Smita Koralahalli
2025-08-22 3:41 ` [PATCH 1/6] dax/hmem, e820, resource: Defer Soft Reserved registration until hmem is ready Smita Koralahalli
2025-09-01 2:59 ` Zhijian Li (Fujitsu)
2025-09-30 4:01 ` Koralahalli Channabasappa, Smita
2025-09-08 23:01 ` dan.j.williams
2025-09-11 19:39 ` Koralahalli Channabasappa, Smita
2025-09-25 18:17 ` dan.j.williams
2025-09-09 16:12 ` Borislav Petkov
2025-09-30 4:56 ` Koralahalli Channabasappa, Smita
2025-12-18 17:52 ` dan.j.williams
2026-01-13 18:29 ` dan.j.williams
2025-08-22 3:41 ` [PATCH 2/6] dax/hmem: Request cxl_acpi and cxl_pci before walking Soft Reserved ranges Smita Koralahalli
2025-09-01 3:08 ` Zhijian Li (Fujitsu)
2025-09-04 17:35 ` Dave Jiang
2025-08-22 3:41 ` [PATCH 3/6] dax/hmem, cxl: Tighten dependencies on DEV_DAX_CXL and dax_hmem Smita Koralahalli
2025-09-01 3:28 ` Zhijian Li (Fujitsu)
2025-09-30 4:04 ` Koralahalli Channabasappa, Smita
2025-08-22 3:42 ` [PATCH 4/6] dax/hmem: Defer Soft Reserved overlap handling until CXL region assembly completes Smita Koralahalli
2025-09-01 4:01 ` Zhijian Li (Fujitsu)
2025-08-22 3:42 ` [PATCH 5/6] dax/hmem: Reintroduce Soft Reserved ranges back into the iomem tree Smita Koralahalli
2025-09-04 18:14 ` Dave Jiang
2025-09-10 13:41 ` Jonathan Cameron
2025-09-30 4:03 ` Koralahalli Channabasappa, Smita
2025-08-22 3:42 ` [RFC PATCH 6/6] cxl/region, dax/hmem: Guard CXL DAX region creation and tighten HMEM deps Smita Koralahalli
2025-09-01 6:21 ` Zhijian Li (Fujitsu)
2025-09-30 4:06 ` Koralahalli Channabasappa, Smita [this message]
2025-08-26 23:21 ` [PATCH 0/6] dax/hmem, cxl: Coordinate Soft Reserved handling with CXL Alison Schofield
2025-08-28 23:34 ` Koralahalli Channabasappa, Smita
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=652a4391-4825-46bf-9f64-52e0ef751dff@amd.com \
--to=skoralah@amd.com \
--cc=PradeepVineshReddy.Kodamati@amd.com \
--cc=Smita.KoralahalliChannabasappa@amd.com \
--cc=alison.schofield@intel.com \
--cc=benjamin.cheatham@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=gregkh@linuxfoundation.org \
--cc=huang.ying.caritas@gmail.com \
--cc=ira.weiny@intel.com \
--cc=jack@suse.cz \
--cc=jeff.johnson@oss.qualcomm.com \
--cc=jonathan.cameron@huawei.com \
--cc=len.brown@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lizhijian@fujitsu.com \
--cc=ming.li@zohomail.com \
--cc=nathan.fontenot@amd.com \
--cc=nvdimm@lists.linux.dev \
--cc=pavel@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rrichter@amd.com \
--cc=terry.bowman@amd.com \
--cc=vishal.l.verma@intel.com \
--cc=willy@infradead.org \
--cc=yaoxt.fnst@fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox