From: Dan Williams <dan.j.williams@intel.com>
To: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>,
<linux-cxl@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Cc: 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>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
Yazen Ghannam <yazen.ghannam@amd.com>,
Dave Jiang <dave.jiang@intel.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Terry Bowman <terry.bowman@amd.com>,
Robert Richter <rrichter@amd.com>,
Benjamin Cheatham <benjamin.cheatham@amd.com>,
Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Subject: Re: [PATCH] cxl/hdm: Avoid DVSEC fallback after region teardown
Date: Tue, 10 Mar 2026 20:22:29 -0700 [thread overview]
Message-ID: <69b0dff5b6043_2132100cd@dwillia2-mobl4.notmuch> (raw)
In-Reply-To: <20260212223800.23624-1-Smita.KoralahalliChannabasappa@amd.com>
Smita Koralahalli wrote:
> After destroy-region, cxl_region_decode_reset() clears the HDM decoder
> registers (base/size/commit). If the memdev is subsequently bounced
> (disable/enable), port probe re-evaluates decoder capability via
> should_emulate_decoders().
I do not think this bug is limited to "after destroy region". Simply, if
the driver sees that the HDM capability is enabled before the driver
loads it indicates that whomever left that configuration also intended
for DVSEC range registers to be ignored.
> The existing logic checks each decoder's COMMITTED bit. Since those bits
> are cleared by region teardown, should_emulate_decoders() incorrectly
> falls back to DVSEC range emulation, even though HDM capability is still
> present.
This is 2 separate bugs, right? Bug 1 destroying the register
configuration of auto-assembled regions, fixed by your pending patch.
Bug 2 destroying auto-assembled regions does not clean up DVSEC range
registers making it look like those are set when HDM decode capability
is disabled. That unintentionally / falsely mimics CXL 1.1 platform
firmware behavior triggering should_emulate_decoders().
> DVSEC fallback marks the endpoint decoder as AUTO, which triggers
> cxl_add_to_region() -> construct_region(). That path copies the default
> interleave_granularity (4096) into the region parameters. The resulting
> spurious autodiscovered region consumes the CFMWS HPA space and causes a
> subsequent create-region to fail in hpa_alloc().
I do not think this part is relevant to the fix, right? Once DVSEC is
being falsely used the rest is just knock-on-effects.
> Use the global CXL_HDM_DECODER_ENABLE bit instead of per-decoder COMMITTED
> bits to detect HDM capability. If the HDM decoder block is enabled,
...if the HDM block is enabled the state of the register is irrelevant.
> registers indicate teardown, not absence of HDM support. This prevents the
> unintended DVSEC fallback and subsequent region creation failure.
I think this wants 2 patches. This one you have here to always trust HDM
decoder on setup, and another patch to teardown non-auto
should_emulate_decoders() DVSEC configurations. Those combined with your
"do not teardown auto regions" should squash this crop of setup bugs.
next prev parent reply other threads:[~2026-03-11 3:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-12 22:38 [PATCH] cxl/hdm: Avoid DVSEC fallback after region teardown Smita Koralahalli
2026-02-13 4:32 ` Alison Schofield
2026-02-17 21:27 ` Koralahalli Channabasappa, Smita
2026-02-17 22:29 ` Dave Jiang
2026-03-11 1:59 ` Alison Schofield
2026-03-11 3:22 ` Dan Williams [this message]
2026-03-12 17:37 ` Koralahalli Channabasappa, Smita
2026-03-12 19:42 ` Dan Williams
2026-03-12 20:55 ` 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=69b0dff5b6043_2132100cd@dwillia2-mobl4.notmuch \
--to=dan.j.williams@intel.com \
--cc=Smita.KoralahalliChannabasappa@amd.com \
--cc=alison.schofield@intel.com \
--cc=benjamin.cheatham@amd.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=ira.weiny@intel.com \
--cc=jonathan.cameron@huawei.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rrichter@amd.com \
--cc=terry.bowman@amd.com \
--cc=vishal.l.verma@intel.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