From: "Dan Williams (nvidia)" <djbw@kernel.org>
To: alejandro.lucero-palau@amd.com, linux-cxl@vger.kernel.org,
djbw@kernel.org, edward.cree@amd.com, davem@davemloft.net,
kuba@kernel.org, pabeni@redhat.com, edumazet@google.com,
dave.jiang@intel.com
Cc: Alejandro Lucero <alucerop@amd.com>
Subject: Re: [PATCH v26 6/8] cxl: attach region to an accelerator/type2 memdev
Date: Thu, 30 Apr 2026 19:00:18 -0700 [thread overview]
Message-ID: <69f409325f7c0_3291a910046@djbw-dev.notmuch> (raw)
In-Reply-To: <20260423180528.17166-7-alejandro.lucero-palau@amd.com>
alejandro.lucero-palau@ wrote:
> From: Alejandro Lucero <alucerop@amd.com>
>
> Support an accelerator driver to safely work with an autodiscovered
> region from a committed HDM decoder through:
>
> 1) an accelerator driver cxl_attach_region struct with attach
> and detach callbacks.
>
> 2) a specific function, cxl_memdev_attach_region() keeping the
> required locks for finding a region linked to the memdev
> endpoint, and
>
> 3) invoking attach callback while keeping the locking allowing to
> work (ioremap and other internal stuff) with the related physical
> range by the accelerator driver, and
>
> 4) linking a detach callback to the endpoint device removal where
> the accelerator driver can stop using the region range.
>
> This covers the cases of a potential removal of cxl_acpi module or a
> accelerator memdev unbinding from cxl_mem driver through sysfs.
>
> Signed-off-by: Alejandro Lucero <alucerop@amd.com>
> ---
> drivers/cxl/core/region.c | 118 ++++++++++++++++++++++++++++-
> drivers/net/ethernet/sfc/efx_cxl.c | 37 +++++++++
> drivers/net/ethernet/sfc/efx_cxl.h | 2 +
> include/cxl/cxl.h | 17 +++++
> 4 files changed, 171 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
> index e50dc716d4e8..68f5a1fd1b1c 100644
> --- a/drivers/cxl/core/region.c
> +++ b/drivers/cxl/core/region.c
> @@ -2711,9 +2711,16 @@ static struct cxl_region *devm_cxl_add_region(struct cxl_root_decoder *cxlrd,
> if (rc)
> goto err;
>
> - rc = devm_add_action_or_reset(port->uport_dev, unregister_region, cxlr);
> - if (rc)
> - return ERR_PTR(rc);
> + /*
> + * For accelerators/type2, region release linked to endpoint device.
> + * See handling of cxl_endpoint_region_autoremove() below by
> + * cxl_memdev_attach_region().
> + */
> + if (type == CXL_DECODER_HOSTONLYMEM) {
> + rc = devm_add_action_or_reset(port->uport_dev, unregister_region, cxlr);
> + if (rc)
> + return ERR_PTR(rc);
> + }
A couple problems here.
1/ Nothing stops a CXL class device from implementing a decoder with
CXL_DECODER_DEVMEM (HDM-DB).
2/ This breaks the automatic cleanup of autoassembly failures in
construct_region().
We simply need to support multiple independent sources of
unregister_region(). Stay tuned for a scheme for that.
>
> dev_dbg(port->uport_dev, "%s: created %s\n",
> dev_name(&cxlrd->cxlsd.cxld.dev), dev_name(dev));
> @@ -4043,6 +4050,111 @@ static int cxl_region_can_probe(struct cxl_region *cxlr)
> return 0;
> }
>
> +static int first_mapped_decoder(struct device *dev, const void *data)
> +{
> + struct cxl_endpoint_decoder *cxled;
> +
> + if (!is_endpoint_decoder(dev))
> + return 0;
> +
> + cxled = to_cxl_endpoint_decoder(dev);
> + if (cxled->cxld.region)
> + return 1;
> +
> + return 0;
> +}
> +
> +/*
> + * As this is running in endpoint port remove context it does not race cxl_root
> + * destruction since port topologies are always removed depth first.
> + */
> +static void cxl_endpoint_region_autoremove(void *_cxlr)
> +{
> + unregister_region(_cxlr);
> +}
> +
> +/**
> + * cxl_memdev_attach_region - bind region to accelerator memdev
> + *
> + * @cxlmd: a pointer to cxl_memdev to use
> + * @attach: a pointer to region attach struct with callbacks for
> + * safely working with a region range by the caller
> + *
> + * Returns 0 or error.
> + */
> +int cxl_memdev_attach_region(struct cxl_memdev *cxlmd,
> + struct cxl_attach_region *attach)
> +{
> + struct cxl_port *endpoint = cxlmd->endpoint;
> + struct cxl_endpoint_decoder *cxled;
> + struct cxl_region *cxlr;
> + int rc;
> +
> + /* hold endpoint lock to setup autoremove of the region */
> + guard(device)(&endpoint->dev);
This does not handle the case when ->endpoint is an ERR_PTR() because
the memdev never attached in the first instance.
> +/* Called at driver exit or when user space triggers cxl region removal. */
> +static void efx_cxl_unmap_region(void *data) {
> + struct efx_probe_data *probe_data = data;
> +
> + probe_data->cxl_pio_initialised = false;
> + iounmap(probe_data->cxl->ctpio_cxl);
> +}
I do not see how an async event can safely zap that ctpio_cxl space with
zero coordination with the driver, and I do not think you want to burden
the fast path with new locks to coordinate this.
Can we please stick with the violent but simple "unload driver" approach
for now? Someone removing cxl_acpi, disabling port drivers, or disabling
the cxl_mem driver gets to keep all the pieces. Just like force
unloading your storage driver underneath your root filesystem. Do not do
it unless you want to see the fireworks or test various hotplug flows.
This graceful handling of something that should never happen, outside of a
test suite exercising CXL core object lifetimes, is not a near term need.
next prev parent reply other threads:[~2026-05-01 2:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-23 18:05 [PATCH v26 0/8] Type2 device basic support alejandro.lucero-palau
2026-04-23 18:05 ` [PATCH v26 1/8] sfc: add cxl support alejandro.lucero-palau
2026-04-29 21:14 ` Cheatham, Benjamin
2026-05-01 10:07 ` Alejandro Lucero Palau
2026-04-23 18:05 ` [PATCH v26 2/8] cxl/sfc: Map cxl regs alejandro.lucero-palau
2026-04-23 18:05 ` [PATCH v26 3/8] cxl/sfc: Initialize dpa without a mailbox alejandro.lucero-palau
2026-04-23 18:05 ` [PATCH v26 4/8] cxl: Prepare memdev creation for type2 alejandro.lucero-palau
2026-04-30 23:23 ` Dan Williams (nvidia)
2026-04-23 18:05 ` [PATCH v26 5/8] sfc: create type2 cxl memdev alejandro.lucero-palau
2026-04-23 18:05 ` [PATCH v26 6/8] cxl: attach region to an accelerator/type2 memdev alejandro.lucero-palau
2026-04-29 21:14 ` Cheatham, Benjamin
2026-05-01 10:35 ` Alejandro Lucero Palau
2026-05-01 2:00 ` Dan Williams (nvidia) [this message]
2026-05-01 10:59 ` Alejandro Lucero Palau
2026-05-02 0:46 ` Dan Williams (nvidia)
2026-05-05 20:51 ` Alejandro Lucero Palau
2026-04-23 18:05 ` [PATCH v26 7/8] cxl: Avoid dax creation for accelerators alejandro.lucero-palau
2026-04-29 21:14 ` Cheatham, Benjamin
2026-04-23 18:05 ` [PATCH v26 8/8] sfc: support pio mapping based on cxl alejandro.lucero-palau
2026-04-23 22:07 ` [PATCH v26 0/8] Type2 device basic support 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=69f409325f7c0_3291a910046@djbw-dev.notmuch \
--to=djbw@kernel.org \
--cc=alejandro.lucero-palau@amd.com \
--cc=alucerop@amd.com \
--cc=dave.jiang@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=edward.cree@amd.com \
--cc=kuba@kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=pabeni@redhat.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