From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Conor Dooley <conor@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
<linux-cxl@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-arch@vger.kernel.org>, <linux-mm@kvack.org>,
Dan Williams <dan.j.williams@intel.com>,
"H . Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>, Drew Fustini <fustini@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Alexandre Belloni <alexandre.belloni@bootlin.com>,
Krzysztof Kozlowski <krzk@kernel.org>
Cc: <james.morse@arm.com>, Will Deacon <will@kernel.org>,
Davidlohr Bueso <dave@stgolabs.net>, <linuxarm@huawei.com>,
Yushan Wang <wangyushan12@huawei.com>,
Lorenzo Pieralisi <lpieralisi@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
<x86@kernel.org>, Andy Lutomirski <luto@kernel.org>,
Dave Jiang <dave.jiang@intel.com>
Subject: [PATCH v5 0/6] Cache coherency management subsystem
Date: Fri, 31 Oct 2025 11:17:03 +0000 [thread overview]
Message-ID: <20251031111709.1783347-1-Jonathan.Cameron@huawei.com> (raw)
Support system level interfaces for cache maintenance as found on some
ARM64 systems. It is expected that systems using other CPU architectures
(such as RiscV) that support CXL memory and allow for native OS flows
will also use this. This is needed for correct functionality during
various forms of memory hotplug (e.g. CXL). Typical hardware has MMIO
interface found via ACPI DSDT. A system will often contain multiple
hardware instances.
Includes parameter changes to cpu_cache_invalidate_memregion() but no
functional changes for architectures that already support this call.
How to merge?
- Current suggestion would be via Conor's drivers/cache tree which routes
through the SoC tree.
* Andrew Morton has expressed he is fine with the MM related changes
going via another appropriate tree.
* CXL maintainers expressed that they don't consider it appropriate
to go through theit tree.
* The tiny touching of Arm specific code has an ack from Catalin.
v5: Changes called out in individual patches.
Comment and patch description updates to make the following clearer.
- Difference from cache-coherence operations for non-coherent DMA.
Longer term it may make sense to share infrastructure but for now
we have two parallel systems as there would be near zero overlap
in code or functionality.
- Why multiple agent handling is necessary and what that means for
the HiSilicon HHAs in our systems + the driver inclued in this set.
v4: (Small changes called out in each patch)
- Drop the ACPI driver. It has done it's job as a second implementation
to help with generality testing. I have heard zero interest in actually
doing the specification work needed to make that official. Easy to bring
back if needed in future. I have it locally still as a second test
case.
- Add a cpu_cache_invalidate_all() helper for the 0,-1 case that is used
to indicate everything should be flushed as no fine grained range info
available.
- Simplify the necessary symbols to be selected by architectures by
making CONFIG_GENERIC_CPU_CACHE_MAINTENANCE select
ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
- Avoid naming mentioning devices as there is no struct device.
- Use a kref so as to have something on which a _put() operation makes
sense avoiding rather confusing freeing of an internal structure pointer
that was seen in v3.
- Gather tags given.
- Various minor things like typos, header tweaks etc.
Thanks to all who reviewed v3.
On current ARM64 systems (and likely other architectures) the
implementation of cache flushing need for actions such as CXL memory
hotplug e.g. cpu_cache_invalidate_memregion(), is performed by system
components outside of the CPU, controlled via either firmware or MMIO
interfaces.
These control units run the necessary coherency protocol operations to
cause the write backs and cache flushes to occur asynchronously. They allow
filtering by PA range to reduce disruption to the system. Systems
supporting this interface must be designed to ensure that, when complete,
all cache lines in the range are in invalid state or clean state
(prefetches may have raced with the invalidation). This must include
memory-side caches and other non architectural caches beyond the Point
of Coherence (ARM terminology) such that writes will reach memory even
after OS programmable address decoders are modified (for CXL this is
any HDM decoders that aren't locked). Software will guarantee that no
writes to these memory ranges race with this operation. Whilst this is
subtly different from write backs must reach the physical memory that
difference probably doesn't matter to those reading this series.
The often distributed nature of the relevant coherency management units
(e.g. due to interleaving) requires the appropriate commands to be issued
to multiple (potentially heterogeneous) units. To enable this a
registration framework is provided to which drivers may register a set
of callbacks. Upon a request for a cache maintenance operation the
framework iterates over all registered callback sets, calling first a
command to write back and invalidate, and then optionally a command to wait
for completion. Filtering on relevance if a give request is left to the
individual drivers.
In this version only one driver is included. This is the HiSilicon Hydra
Home Agent driver which controls hardware found on some of our relevant
server SoCs. Also available (I can post if anyone is interested)
is an ACPI driver based on a firmware interface that was in a public
PSCI specification alpha version
QEMU emulation code at
http://gitlab.com/jic23/qemu cxl-2025-03-20
Notes:
- I don't particularly like defining 'generic' infrastructure with so few
implementations. If anyone can point me at docs for another one or two,
or confirm that they think this is fine that would be great!
The converse to this is I don't want to wait longer for those to surface
given the necessity to support this one platform that I do know about!
Jonathan Cameron (3):
memregion: Drop unused IORES_DESC_* parameter from
cpu_cache_invalidate_memregion()
arm64: Select GENERIC_CPU_CACHE_MAINTENANCE
MAINTAINERS: Add Jonathan Cameron to drivers/cache and add
lib/cache_maint.c + header
Yicong Yang (2):
memregion: Support fine grained invalidate by
cpu_cache_invalidate_memregion()
lib: Support ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
Yushan Wang (1):
cache: Support cache maintenance for HiSilicon SoC Hydra Home Agent
MAINTAINERS | 3 +
arch/arm64/Kconfig | 1 +
arch/x86/mm/pat/set_memory.c | 2 +-
drivers/cache/Kconfig | 15 +++
drivers/cache/Makefile | 2 +
drivers/cache/hisi_soc_hha.c | 194 ++++++++++++++++++++++++++++++++
drivers/cxl/core/region.c | 5 +-
drivers/nvdimm/region.c | 2 +-
drivers/nvdimm/region_devs.c | 2 +-
include/linux/cache_coherency.h | 61 ++++++++++
include/linux/memregion.h | 16 ++-
lib/Kconfig | 4 +
lib/Makefile | 2 +
lib/cache_maint.c | 138 +++++++++++++++++++++++
14 files changed, 439 insertions(+), 8 deletions(-)
create mode 100644 drivers/cache/hisi_soc_hha.c
create mode 100644 include/linux/cache_coherency.h
create mode 100644 lib/cache_maint.c
--
2.48.1
next reply other threads:[~2025-10-31 11:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-31 11:17 Jonathan Cameron [this message]
2025-10-31 11:17 ` [PATCH v5 1/6] memregion: Drop unused IORES_DESC_* parameter from cpu_cache_invalidate_memregion() Jonathan Cameron
2025-10-31 11:17 ` [PATCH v5 2/6] memregion: Support fine grained invalidate by cpu_cache_invalidate_memregion() Jonathan Cameron
2025-10-31 11:17 ` [PATCH v5 3/6] lib: Support ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION Jonathan Cameron
2025-10-31 11:17 ` [PATCH v5 4/6] arm64: Select GENERIC_CPU_CACHE_MAINTENANCE Jonathan Cameron
2025-10-31 11:17 ` [PATCH v5 5/6] MAINTAINERS: Add Jonathan Cameron to drivers/cache and add lib/cache_maint.c + header Jonathan Cameron
2025-10-31 11:17 ` [PATCH v5 6/6] cache: Support cache maintenance for HiSilicon SoC Hydra Home Agent Jonathan Cameron
2025-11-08 20:02 ` [PATCH v5 0/6] Cache coherency management subsystem Conor Dooley
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=20251031111709.1783347-1-Jonathan.Cameron@huawei.com \
--to=jonathan.cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=alexandre.belloni@bootlin.com \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=conor@kernel.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=fustini@kernel.org \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=krzk@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxarm@huawei.com \
--cc=lpieralisi@kernel.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=wangyushan12@huawei.com \
--cc=will@kernel.org \
--cc=x86@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;
as well as URLs for NNTP newsgroup(s).