From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Dave Jiang <dave.jiang@intel.com>
Cc: <linux-cxl@vger.kernel.org>, <dave@stgolabs.net>,
<alison.schofield@intel.com>, <vishal.l.verma@intel.com>,
<ira.weiny@intel.com>, <dan.j.williams@intel.com>
Subject: Re: [PATCH] cxl: Add handling of locked CXL decoder
Date: Tue, 28 Oct 2025 14:39:14 +0000 [thread overview]
Message-ID: <20251028143914.00004f46@huawei.com> (raw)
In-Reply-To: <20251021205055.2081800-1-dave.jiang@intel.com>
On Tue, 21 Oct 2025 13:50:55 -0700
Dave Jiang <dave.jiang@intel.com> wrote:
> When a decoder is locked, it means that its configuration cannot be
> changed. CXL spec r3.2 8.2.4.20.13 discusses the details regarding
> locked decoders. Locking happens when bit 8 of the decoder control
> register is set and then the decoder is committed afterwards (CXL
> spec r3.2 8.2.4.20.7).
>
> Given that the driver creates a virtual decoder for each CFMWS, the
> Fixed Device Configuration (bit 4) of the Window Restriction field is
> considered as locking for the virtual decoder by the driver.
>
> The current driver code disregards the locked status and a region can
> be destroyed regardless of the locking state.
>
> Add a region flag to indicate the region is in a locked configuration.
> The driver will considered a region locked if the CFMWS or any decoder
> is configured as locked. The consideration is all or nothing regarding
> the locked state. It is reasonable to determine the region "locked"
> status while the region is being assembled based on the decoders.
>
> Add a check in region commit_store() to intercept when a 0 is written
> to the commit sysfs attribute in order to prevent the destruction of a
> region when in locked state. This should be the only entry point from user
> space to destroy a region.
>
> Add a check is added to cxl_decoder_reset() to prevent resetting a locked
> decoder within the kernel driver.
>
> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Fully agree with what should be happening here, but a question below
on the implementation.
> ---
> drivers/cxl/core/hdm.c | 3 +++
> drivers/cxl/core/region.c | 16 ++++++++++++++++
> drivers/cxl/cxl.h | 8 ++++++++
> 3 files changed, 27 insertions(+)
>
> diff --git a/drivers/cxl/core/hdm.c b/drivers/cxl/core/hdm.c
> index d3a094ca01ad..1c5d2022c87a 100644
> --- a/drivers/cxl/core/hdm.c
> +++ b/drivers/cxl/core/hdm.c
> @@ -905,6 +905,9 @@ static void cxl_decoder_reset(struct cxl_decoder *cxld)
> if ((cxld->flags & CXL_DECODER_F_ENABLE) == 0)
> return;
>
> + if (test_bit(CXL_DECODER_F_LOCK, &cxld->flags))
> + return;
> +
> if (port->commit_end == id)
> cxl_port_commit_reap(cxld);
> else
> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> index b06fee1978ba..8647eff4fb78 100644
> --- a/drivers/cxl/core/region.c
> +++ b/drivers/cxl/core/region.c
> @@ -419,6 +419,9 @@ static ssize_t commit_store(struct device *dev, struct device_attribute *attr,
> return len;
> }
>
> + if (test_bit(CXL_REGION_F_LOCK, &cxlr->flags))
> + return -EPERM;
> +
> rc = queue_reset(cxlr);
> if (rc)
> return rc;
> @@ -1059,6 +1062,16 @@ static int cxl_rr_assign_decoder(struct cxl_port *port, struct cxl_region *cxlr,
> return 0;
> }
>
> +static void cxl_region_set_lock(struct cxl_region *cxlr,
> + struct cxl_decoder *cxld)
> +{
> + if (!test_bit(CXL_REGION_F_LOCK, &cxlr->flags))
> + return;
> +
> + set_bit(CXL_REGION_F_LOCK, &cxlr->flags);
The sequence above here looks odd. If the bit is not set, then don't
set it? If already set then set it again? Was one of these meant to be
related to the decoder that was passed in?
Maybe I need more coffee...
> + clear_bit(CXL_REGION_F_NEEDS_RESET, &cxlr->flags);
> +}
> +
> /**
> * cxl_port_attach_region() - track a region's interest in a port by endpoint
> * @port: port to add a new region reference 'struct cxl_region_ref'
> @@ -1170,6 +1183,8 @@ static int cxl_port_attach_region(struct cxl_port *port,
> }
> }
>
> + cxl_region_set_lock(cxlr, cxld);
> +
> rc = cxl_rr_ep_add(cxl_rr, cxled);
> if (rc) {
> dev_dbg(&cxlr->dev,
> @@ -2439,6 +2454,7 @@ static struct cxl_region *cxl_region_alloc(struct cxl_root_decoder *cxlrd, int i
> dev->bus = &cxl_bus_type;
> dev->type = &cxl_region_type;
> cxlr->id = id;
> + cxl_region_set_lock(cxlr, &cxlrd->cxlsd.cxld);
>
> return cxlr;
> }
> diff --git a/drivers/cxl/cxl.h b/drivers/cxl/cxl.h
> index 231ddccf8977..6382f1983865 100644
> --- a/drivers/cxl/cxl.h
> +++ b/drivers/cxl/cxl.h
> @@ -517,6 +517,14 @@ enum cxl_partition_mode {
> */
> #define CXL_REGION_F_NEEDS_RESET 1
>
> +/*
> + * Indicate whether this region is locked due to 1 or more decoders that have
> + * been locked. The approach of all or nothing is taken with regard to the
> + * locked attribute. CXL_REGION_F_NEEDS_RESET should not be set if this flag is
> + * set.
> + */
> +#define CXL_REGION_F_LOCK 2
> +
> /**
> * struct cxl_region - CXL region
> * @dev: This region's device
>
> base-commit: 211ddde0823f1442e4ad052a2f30f050145ccada
next prev parent reply other threads:[~2025-10-28 14:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-21 20:50 [PATCH] cxl: Add handling of locked CXL decoder Dave Jiang
2025-10-28 14:39 ` Jonathan Cameron [this message]
2025-10-28 15:17 ` Dave Jiang
2025-10-29 16:17 ` Alejandro Lucero Palau
2025-10-31 23:16 ` Dave Jiang
2025-11-03 11:25 ` Alejandro Lucero Palau
2025-11-03 15:19 ` Dave Jiang
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=20251028143914.00004f46@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=vishal.l.verma@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.