From: Jonathan Cameron <jonathan.cameron@huawei.com>
To: Davidlohr Bueso <dave@stgolabs.net>
Cc: <dave.jiang@intel.com>, <alison.schofield@intel.com>,
<ira.weiny@intel.com>, <dan.j.williams@intel.com>,
<dongjoo.seo1@samsung.com>, <anisa.su@samsung.com>,
<linux-cxl@vger.kernel.org>
Subject: Re: [RFC PATCH 0/1] cxl: Media Operations
Date: Tue, 24 Mar 2026 15:32:38 +0000 [thread overview]
Message-ID: <20260324153238.0000750e@huawei.com> (raw)
In-Reply-To: <20260323204013.4010634-1-dave@stgolabs.net>
On Mon, 23 Mar 2026 13:40:12 -0700
Davidlohr Bueso <dave@stgolabs.net> wrote:
> Hello,
>
> This implements support for Media Operation cmd. It is marked RFC because of these
> noteworthy points:
>
> (i) Sysfs interfaces. These changes implement 'security/zero' and multiplex
> 'security/sanitize' to allow dpa, len pairs for the range (no impact for
> current usage as whole-device). This breaks the 1 value per file "rule",
> and would be a first for drivers/cxl/*, so am I open to suggestions.
Value is a vague sort of term. It's one thing (an range) so seems fine to me.
>
> (ii) Background cmd handling semantics. Media operations are synchronous,
> which for raged zeroing operations makes sense and for range sanitize
ranged
> differs from the current async handling for whole-device, so user response
> differs significantly, something I am not crazy about. Another downside
> of this is that it exposes lock hold times to be user-controllable, but is
> no different than what we do for fw. Fundamentally, users have the
> responsibility to break up the work into sane ranges.
We could apply a limit on this and make that discoverable via another sysfs attribute.
So let userspace request in say 1Gig chunks. Would have to check that the device
supports that granularity though.
I don't think there is anything in the spec today to let us query how long
something takes (which would be a better way to bound this).
> Further, this is
> without considering abortable bg cmds[0], which, per-spec, are unsupported
> today for media operations.
>
> Tested with qemu + fixlets (https://lore.kernel.org/all/20260319184256.3762391-1-dave@stgolabs.net/)
I think those all landed upstream today and are getting pulled into qemu stable as well.
>
> Applies against latest 'next' from cxl.git.
>
> [0] https://lore.kernel.org/all/20250617193611.564668-1-dave@stgolabs.net/
>
> Thanks!
>
> Davidlohr Bueso (1):
> cxl/mbox: Support Media Operation
>
> Documentation/ABI/testing/sysfs-bus-cxl | 31 +++-
> drivers/cxl/core/mbox.c | 235 ++++++++++++++++++++++++
> drivers/cxl/core/memdev.c | 45 ++++-
> drivers/cxl/cxlmem.h | 59 ++++++
> drivers/cxl/pci.c | 4 +
> 5 files changed, 369 insertions(+), 5 deletions(-)
>
> --
> 2.39.5
>
>
next prev parent reply other threads:[~2026-03-24 15:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-23 20:40 [RFC PATCH 0/1] cxl: Media Operations Davidlohr Bueso
2026-03-23 20:40 ` [PATCH 1/1] cxl/mbox: Support Media Operation Davidlohr Bueso
2026-03-24 16:18 ` Jonathan Cameron
2026-03-24 18:40 ` Davidlohr Bueso
2026-03-25 13:47 ` kernel test robot
2026-03-25 15:55 ` kernel test robot
2026-03-24 15:32 ` Jonathan Cameron [this message]
2026-03-24 18:07 ` [RFC PATCH 0/1] cxl: Media Operations Davidlohr Bueso
2026-03-25 12:06 ` Jonathan Cameron
2026-03-27 15:17 ` John Groves
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=20260324153238.0000750e@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=alison.schofield@intel.com \
--cc=anisa.su@samsung.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=dongjoo.seo1@samsung.com \
--cc=ira.weiny@intel.com \
--cc=linux-cxl@vger.kernel.org \
/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