From: Jonathan Cameron <jic23@kernel.org>
To: Srirangan Madhavan <smadhavan@nvidia.com>
Cc: catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
lpieralisi@kernel.org, sudeep.holla@arm.com, conor@kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, vsethi@nvidia.com,
jevans@nvidia.com, raghupathyk@nvidia.com, srikars@nvidia.com,
nbenech@nvidia.com, alwilliamson@nvidia.com,
Dan Williams <danwilliams@nvidia.com>
Subject: Re: [RFC PATCH 0/2] arm64: add SMCCC cache invalidation backend for memregion users
Date: Thu, 21 May 2026 12:28:34 +0100 [thread overview]
Message-ID: <20260521122820.35fd34af@jic23-huawei> (raw)
In-Reply-To: <20260521073047.320614-1-smadhavan@nvidia.com>
On Thu, 21 May 2026 07:30:45 +0000
Srirangan Madhavan <smadhavan@nvidia.com> wrote:
> This series adds an arm64 backend for memregion cache invalidation users
> based on the Arm SMCCC cache clean+invalidate interface.
>
> Per DEN0028, this interface targets systems where a Normal Cacheable
> memory region can be modified in ways that are not handled by usual PE
> coherency mechanisms, and where VA-based CMOs may be too slow or
> insufficient for large ranges and/or system-cache implementations.
>
> Representative use cases include device-backed memory state transitions
> where stale CPU/system cache lines must be invalidated reliably (for
> example secure erase, reset/offline flows, and dynamic memory
> reconfiguration).
>
Hi Srirangan,
Great to see this moving forwards. I was wondering when it would
surface upstream :)
Usual thing for an RFC is to have some reference to why it is an RFC.
I'm not immediately spotting any open questions or dependencies to
stop this going upstream now (if review of actual code goes well).
So why RFC? Is the spec still in beta?
> Patch 1 introduces the Arm SMCCC cache clean/invalidate function IDs and
> transient return codes needed by callers [1].
>
> Patch 2 adds an arm64 cache maintenance provider that:
> - discovers SMCCC support and attributes at init time
> - registers with the generic cache coherency framework used by
> cpu_cache_invalidate_memregion()
> - handles transient BUSY/RATE_LIMITED responses with bounded retries
> - coalesces waiters when firmware reports a global operation type
>
> This patch set does not add a software fallback path; when firmware does
> not implement the SMCCC cache maintenance interface, the provider is not
> registered and existing behavior is preserved.
By which you mean it kicks out an error? This kind of hints there
might be a software fallback (assuming no other implementation has
registered). In many cases there isn't a safe software solution.
Jonathan
>
> Reference:
> [1] https://developer.arm.com/documentation/den0028/latest
>
> Srirangan Madhavan (2):
> arm64: smccc: add cache clean/invalidate IDs and return codes
> arm64: mm: add SMCCC-backed cache invalidate provider
>
> MAINTAINERS | 1 +
> arch/arm64/mm/Makefile | 1 +
> arch/arm64/mm/cache_maint.c | 180 ++++++++++++++++++++++++++++++++
> include/linux/arm-smccc.h | 17 ++-
> tools/include/linux/arm-smccc.h | 17 ++-
> 5 files changed, 212 insertions(+), 4 deletions(-)
> create mode 100644 arch/arm64/mm/cache_maint.c
>
>
> base-commit: 3b3bea6d4b9c162f9e555905d96b8c1da67ecd5b
prev parent reply other threads:[~2026-05-21 11:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-21 7:30 [RFC PATCH 0/2] arm64: add SMCCC cache invalidation backend for memregion users Srirangan Madhavan
2026-05-21 7:30 ` [RFC PATCH 1/2] arm64: smccc: add cache clean/invalidate IDs and return codes Srirangan Madhavan
2026-05-21 7:30 ` [RFC PATCH 2/2] arm64: mm: add SMCCC-backed cache invalidate provider Srirangan Madhavan
2026-05-21 11:18 ` Jonathan Cameron
2026-05-21 14:12 ` Conor Dooley
2026-05-21 16:35 ` Catalin Marinas
2026-05-21 20:10 ` Dan Williams (nvidia)
2026-05-21 11:28 ` Jonathan Cameron [this message]
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=20260521122820.35fd34af@jic23-huawei \
--to=jic23@kernel.org \
--cc=alwilliamson@nvidia.com \
--cc=catalin.marinas@arm.com \
--cc=conor@kernel.org \
--cc=danwilliams@nvidia.com \
--cc=jevans@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mark.rutland@arm.com \
--cc=nbenech@nvidia.com \
--cc=raghupathyk@nvidia.com \
--cc=smadhavan@nvidia.com \
--cc=srikars@nvidia.com \
--cc=sudeep.holla@arm.com \
--cc=vsethi@nvidia.com \
--cc=will@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