From: Alison Schofield <alison.schofield@intel.com>
To: Srirangan Madhavan <smadhavan@nvidia.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Dave Jiang <dave.jiang@intel.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Ira Weiny <ira.weiny@intel.com>,
Jonathan Cameron <jic23@kernel.org>,
Vishal Verma <vishal.l.verma@intel.com>,
<linux-cxl@vger.kernel.org>, <linux-pci@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
Alex Williamson <alex.williamson@redhat.com>, <vsethi@nvidia.com>,
<alwilliamson@nvidia.com>,
Sai Yashwanth Reddy Kancherla <skancherla@nvidia.com>,
Vishal Aslot <vaslot@nvidia.com>,
Manish Honap <mhonap@nvidia.com>, Jiandi An <jan@nvidia.com>,
Richard Cheng <icheng@nvidia.com>, <linux-tegra@vger.kernel.org>
Subject: Re: [PATCH v15 11/16] cxl: Validate and synchronize HDM ranges around reset
Date: Mon, 26 Oct 2026 20:25:58 -0700 [thread overview]
Message-ID: <auAZxpEJ6ojhu5gW@aschofie-mobl2.lan> (raw)
In-Reply-To: <20261011021422.3428136-12-smadhavan@nvidia.com>
On Sun, Oct 11, 2026 at 02:14:17AM +0000, Srirangan Madhavan wrote:
> Refuse reset unless enabled system-physical HDM ranges can be reserved
> exclusively and CPU-cache invalidation is available. Invalidate before
> reset and again before ending IOMMU exclusion, holding range reservations
> until the second invalidation completes. A later patch places state
> restoration before the second invalidation.
>
> Reject normalized-addressing decoders because their cached ranges are not
> system physical addresses. Ignore zero-size decoders because they map no
> address range. Refuse reset when the device decodes memory through its
> DVSEC ranges instead of HDM decoders, since the cache holds no range to
> reserve for that memory.
>
> Provide the range handling as a region quiesce in built-in CXL code. The
> quiesce lock blocks region commit and teardown for the whole reset, and
> the HDM state copy taken under it supplies both the reserved ranges and,
> later, the state to restore.
Hi Srirangan,
Is above statement underselling the potential impact? The quiesce is
cxl_rwsem.region held for write, so for the whole reset it also blocks
region and decoder sysfs, region probe, poison list/inject/clear, sanitize
and event record tracing, on every CXL device.
Can the changelog say what it blocks and for how long?
more below on the 'how long' ?
snip
> +static int cxl_reset_execute(struct pci_dev *pdev, int dvsec, u16 cap)
> +{
> + int rc;
> +
> + cxl_region_quiesce_lock();
> + rc = cxl_reset_quiesced(pdev, dvsec, cap);
> + cxl_region_quiesce_unlock();
IIUC, this cxl_rwsem.region for write for the whole reset, including the
Memory Clear wait, which can run to CXL_RESET_MAX_WAIT_MS (20 seconds) plus
the cache flushes. That blocks all region activity, on every CXL device in
the system, not just the one being reset. Does resetting one device need
to stop all of it?
snip
> +/**
> + * struct cxl_hdm_range - HPA range held exclusively across a reset
> + * @list: entry in &cxl_hdm_quiesce.ranges
> + * @dev: device for error messages
> + * @hpa_range: system physical address range decoded by the device
> + * @len: length of @hpa_range
> + * @res: reservation of @hpa_range, once requested
> + */
> +struct cxl_hdm_range {
> + struct list_head list;
> + struct device *dev;
Can these range helpers return the error and leave the reporting to
cxl_reset_quiesced()? That was the v14 ask. v15 swaps struct pci_dev for
struct device, but the device is still passed down through
cxl_hdm_quiesce_prepare() and stored here only for dev_err().
-- Alison
next prev parent reply other threads:[~2026-10-27 3:26 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-11 2:14 [PATCH v15 00/16] PCI/CXL: Add CXL reset support for Type 2 devices Srirangan Madhavan
2026-10-11 2:14 ` [PATCH v15 01/16] cxl: Drop stale decoder interleave limit comment Srirangan Madhavan
2026-10-27 4:13 ` Alison Schofield
2026-10-11 2:14 ` [PATCH v15 02/16] cxl: Share CXL port upstream PCI device lookup Srirangan Madhavan
2026-10-11 2:14 ` [PATCH v15 03/16] cxl: Move decoder declarations to shared header Srirangan Madhavan
2026-10-11 2:14 ` [PATCH v15 04/16] cxl: Embed decoder configuration in a standalone structure Srirangan Madhavan
2026-10-11 2:14 ` [PATCH v15 05/16] cxl: Introduce endpoint HDM decoder settings Srirangan Madhavan
2026-10-26 22:20 ` Dave Jiang
2026-10-27 6:23 ` Li Ming
2026-10-11 2:14 ` [PATCH v15 06/16] cxl: Move HDM decoder helpers to built-in code Srirangan Madhavan
2026-10-26 22:32 ` Dave Jiang
2026-10-27 6:24 ` Li Ming
2026-10-11 2:14 ` [PATCH v15 07/16] cxl: Share HDM decoder register unpacking Srirangan Madhavan
2026-10-26 22:41 ` Dave Jiang
2026-10-27 6:31 ` Li Ming
2026-10-11 2:14 ` [PATCH v15 08/16] cxl: Refresh cached PCI HDM decoder settings Srirangan Madhavan
2026-10-26 22:56 ` Dave Jiang
2026-10-27 6:50 ` Li Ming
2026-10-11 2:14 ` [PATCH v15 09/16] PCI/CXL: Cache endpoint HDM state during PCI enumeration Srirangan Madhavan
2026-10-27 8:07 ` Li Ming
2026-10-11 2:14 ` [PATCH v15 10/16] PCI/CXL: Add CXL Device Reset sequencing Srirangan Madhavan
2026-10-11 2:14 ` [PATCH v15 11/16] cxl: Validate and synchronize HDM ranges around reset Srirangan Madhavan
2026-10-27 3:25 ` Alison Schofield [this message]
2026-10-27 4:32 ` Alison Schofield
2026-10-11 2:14 ` [PATCH v15 12/16] PCI/CXL: Reject reset with unsafe function scope Srirangan Madhavan
2026-10-11 2:14 ` [PATCH v15 13/16] PCI/CXL: Restore CXL state after PCI reset Srirangan Madhavan
2026-10-27 3:56 ` Alison Schofield
2026-10-11 2:14 ` [PATCH v15 14/16] PCI/CXL: Expose CXL Reset as a PCI reset method Srirangan Madhavan
2026-10-11 2:14 ` [PATCH v15 15/16] PCI/CXL: Restore CXL state after CXL bus reset Srirangan Madhavan
2026-10-11 2:14 ` [PATCH v15 16/16] tools/testing/cxl: Add HDM decoder range checks Srirangan Madhavan
2026-10-27 2:41 ` Alison Schofield
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=auAZxpEJ6ojhu5gW@aschofie-mobl2.lan \
--to=alison.schofield@intel.com \
--cc=alex.williamson@redhat.com \
--cc=alwilliamson@nvidia.com \
--cc=bhelgaas@google.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=icheng@nvidia.com \
--cc=ira.weiny@intel.com \
--cc=jan@nvidia.com \
--cc=jic23@kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=mhonap@nvidia.com \
--cc=skancherla@nvidia.com \
--cc=smadhavan@nvidia.com \
--cc=vaslot@nvidia.com \
--cc=vishal.l.verma@intel.com \
--cc=vsethi@nvidia.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
all inboxes | Powered by JetHome®