From: <dan.j.williams@intel.com>
To: "Yasunori Gotou (Fujitsu)" <y-goto@fujitsu.com>,
"'dan.j.williams@intel.com'" <dan.j.williams@intel.com>,
"Tomasz Wolski (Fujitsu)" <tomasz.wolski@fujitsu.com>,
"alison.schofield@intel.com" <alison.schofield@intel.com>
Cc: "Smita.KoralahalliChannabasappa@amd.com"
<Smita.KoralahalliChannabasappa@amd.com>,
"ardb@kernel.org" <ardb@kernel.org>,
"benjamin.cheatham@amd.com" <benjamin.cheatham@amd.com>,
"bp@alien8.de" <bp@alien8.de>,
"dave.jiang@intel.com" <dave.jiang@intel.com>,
"dave@stgolabs.net" <dave@stgolabs.net>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"huang.ying.caritas@gmail.com" <huang.ying.caritas@gmail.com>,
"ira.weiny@intel.com" <ira.weiny@intel.com>,
"jack@suse.cz" <jack@suse.cz>,
"jeff.johnson@oss.qualcomm.com" <jeff.johnson@oss.qualcomm.com>,
"jonathan.cameron@huawei.com" <jonathan.cameron@huawei.com>,
"len.brown@intel.com" <len.brown@intel.com>,
"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
"Zhijian Li (Fujitsu)" <lizhijian@fujitsu.com>,
"ming.li@zohomail.com" <ming.li@zohomail.com>,
"nathan.fontenot@amd.com" <nathan.fontenot@amd.com>,
"nvdimm@lists.linux.dev" <nvdimm@lists.linux.dev>,
"pavel@kernel.org" <pavel@kernel.org>,
"peterz@infradead.org" <peterz@infradead.org>,
"rafael@kernel.org" <rafael@kernel.org>,
"rrichter@amd.com" <rrichter@amd.com>,
"terry.bowman@amd.com" <terry.bowman@amd.com>,
"vishal.l.verma@intel.com" <vishal.l.verma@intel.com>,
"willy@infradead.org" <willy@infradead.org>,
"Xingtao Yao (Fujitsu)" <yaoxt.fnst@fujitsu.com>,
"yazen.ghannam@amd.com" <yazen.ghannam@amd.com>
Subject: RE: [PATCH v4 0/9] dax/hmem, cxl: Coordinate Soft Reserved handling with CXL and HMEM
Date: Fri, 5 Dec 2025 16:11:34 -0800 [thread overview]
Message-ID: <693374b63fed_1b2e10063@dwillia2-mobl4.notmuch> (raw)
In-Reply-To: <OS9PR01MB124214C25B1A4A4FA1075CADA90A7A@OS9PR01MB12421.jpnprd01.prod.outlook.com>
Yasunori Gotou (Fujitsu) wrote:
[..]
> > > == plug - after PCI rescan cannot create hmem 6070000000-a06fffffff :
> > > CXL Window 1
> > > 6070000000-a06fffffff : region1
> > >
> > > kernel: cxl_region region1: config state: 0
> > > kernel: cxl_acpi ACPI0017:00: decoder0.1: created region1
> > > kernel: cxl_pci 0000:04:00.0: mem1:decoder10.0: __construct_region
> > > region1 res: [mem 0x6070000000-0xa06fffffff flags 0x200] iw: 1 ig:
> > > 4096
> > > kernel: cxl_mem mem1: decoder:decoder10.0 parent:0000:04:00.0
> > > port:endpoint10 range:0x6070000000-0xa06fffffff pos:0
> > > kernel: cxl region1: region sort successful
> > > kernel: cxl region1: mem1:endpoint10 decoder10.0 add: mem1:decoder10.0
> > > @ 0 next: none nr_eps: 1 nr_targets: 1
> > > kernel: cxl region1: pci0000:00:port2 decoder2.1 add: mem1:decoder10.0
> > > @ 0 next: mem1 nr_eps: 1 nr_targets: 1
> > > kernel: cxl region1: pci0000:00:port2 cxl_port_setup_targets expected
> > > iw: 1 ig: 4096 [mem 0x6070000000-0xa06fffffff flags 0x200]
> > > kernel: cxl region1: pci0000:00:port2 cxl_port_setup_targets got iw: 1
> > > ig: 256 state: disabled 0x6070000000:0xa06fffffff
> >
> > Did the device get reset in the process? This looks like decoders bounced in an
> > inconsistent fashion from unplug to replug and autodiscovery.
>
> You are correct.
> This environment does not support actual PCIe hotplug.
> Even if we perform PCIe hotplug emulation by manipulating sysfs, some CXL Decoder registers,
> which have read-only attributes, are not initialized.
> I confirmed about a month and a half ago that this was causing the hot-add process to fail.
> I suspect that such registers must be initialized by the hardware when a hot-add occurs.
>
> I should have informed Wolski-san about this in advance. My apologies.
No worries, just wanted to understand what was happening, thanks for
confirming.
However, this does raise an important issue that tooling could solve. If
you are committed to unplugging a device and the decoders are locked
then tooling should probably arrange for a secondary bus reset to unlock
and disable those decoders. Otherwise, the kernel might have a hard time
guaranteeing that a removed device restores at the exact address it had
previously, especially when there is free CFMWS capacity.
next prev parent reply other threads:[~2025-12-06 0:11 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-20 3:19 [PATCH v4 0/9] dax/hmem, cxl: Coordinate Soft Reserved handling with CXL and HMEM Smita Koralahalli
2025-11-20 3:19 ` [PATCH v4 1/9] dax/hmem, e820, resource: Defer Soft Reserved insertion until hmem is ready Smita Koralahalli
2025-12-02 22:19 ` dan.j.williams
2025-12-11 23:20 ` Koralahalli Channabasappa, Smita
2025-12-02 23:31 ` Dave Jiang
2025-11-20 3:19 ` [PATCH v4 2/9] dax/hmem: Request cxl_acpi and cxl_pci before walking Soft Reserved ranges Smita Koralahalli
2025-11-20 3:19 ` [PATCH v4 3/9] dax/hmem: Gate Soft Reserved deferral on DEV_DAX_CXL Smita Koralahalli
2025-12-02 23:32 ` Dave Jiang
2025-11-20 3:19 ` [PATCH v4 4/9] dax/hmem: Defer handling of Soft Reserved ranges that overlap CXL windows Smita Koralahalli
2025-12-02 22:37 ` dan.j.williams
2025-12-11 23:23 ` Koralahalli Channabasappa, Smita
2025-11-20 3:19 ` [PATCH v4 5/9] cxl/region, dax/hmem: Arbitrate Soft Reserved ownership with cxl_regions_fully_map() Smita Koralahalli
2025-12-03 3:50 ` dan.j.williams
2025-12-11 23:42 ` Koralahalli Channabasappa, Smita
2025-11-20 3:19 ` [PATCH v4 6/9] cxl/region: Add register_dax flag to defer DAX setup Smita Koralahalli
2025-11-20 18:17 ` Koralahalli Channabasappa, Smita
2025-11-20 20:21 ` kernel test robot
2025-12-04 0:22 ` dan.j.williams
2025-11-20 3:19 ` [PATCH v4 7/9] cxl/region, dax/hmem: Register cxl_dax only when CXL owns Soft Reserved span Smita Koralahalli
2025-11-20 3:19 ` [PATCH v4 8/9] cxl/region, dax/hmem: Tear down CXL regions when HMEM reclaims Soft Reserved Smita Koralahalli
2025-12-04 0:50 ` dan.j.williams
2025-11-20 3:19 ` [PATCH v4 9/9] dax/hmem: Reintroduce Soft Reserved ranges back into the iomem tree Smita Koralahalli
2025-12-04 0:54 ` dan.j.williams
2025-12-01 19:56 ` [PATCH v4 0/9] dax/hmem, cxl: Coordinate Soft Reserved handling with CXL and HMEM Alison Schofield
2025-12-03 13:35 ` Tomasz Wolski
2025-12-03 22:05 ` dan.j.williams
2025-12-05 2:54 ` Yasunori Gotou (Fujitsu)
2025-12-05 23:04 ` Tomasz Wolski
2025-12-06 0:11 ` dan.j.williams [this message]
2025-12-02 6:41 ` dan.j.williams
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=693374b63fed_1b2e10063@dwillia2-mobl4.notmuch \
--to=dan.j.williams@intel.com \
--cc=Smita.KoralahalliChannabasappa@amd.com \
--cc=alison.schofield@intel.com \
--cc=ardb@kernel.org \
--cc=benjamin.cheatham@amd.com \
--cc=bp@alien8.de \
--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=tomasz.wolski@fujitsu.com \
--cc=vishal.l.verma@intel.com \
--cc=willy@infradead.org \
--cc=y-goto@fujitsu.com \
--cc=yaoxt.fnst@fujitsu.com \
--cc=yazen.ghannam@amd.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;
as well as URLs for NNTP newsgroup(s).