Support system level interfaces for cache maintenance as found on some
ARM64 systems. This is needed for correct functionality during various
forms of memory hotplug (e.g. CXL). Typical hardware has MMIO interface
found via ACPI DSDT.
Includes parameter changes to cpu_cache_invalidate_memregion() but no
functional changes for architectures that already support this call.
v3:
- Squash the layers by moving all the management code into
lib/cache_maint.c that architectures can opt into via
GENERIC_CPU_CACHE_MAINTENANCE (Dan). I added entries to Conor's
drivers/cache MAINTAINERS entry to include this lib/ code but if
preferred I can add a separate entry for it.
- Add a new patch 1 that drops the old IODESC_RES_ parameter as it never
did anything other than document intent. With the addition of a
flushing range, we would have to check the range and resource type
matched. Simpler to just drop the parameter. (Dan)
- Minor fixes and renames as per reviews.
- Even if all else looks good, I fully expect some discussion of the
naming as I'm not particularly happy with it.
- Open question on whether is acceptable for the answer to whether
cpu_cache_invalidate_memregion() is supported to change as drivers
register (potentially after initial boot). Could design a firmware
table solution to this, but will take a while - not sure if it is
necessary.
- Switch to a fwctl style allocation function that makes the container
nature of the allocation explicit.
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. The 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 possible 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 is left to the individual drivers.
Two drivers are included. This HiSilicon Hydra Home Agent driver which
controls hardware found on some of our relevant server SoCs and,
mostly to show that the approach is general, a driver based on a firmware
interface that was in a public PSCI specification alpha version
(now dropped - don't merge that!)
QEMU emulation code at
http://gitlab.com/jic23/qemu cxl-2025-03-20
Remaining opens:
- Naming. All suggestions welcome!
- 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!
- I made up the ACPI spec - it's not documented, non official and honestly
needs work. I would however like to get feedback on whether it is
something we want to try and get through the ACPI Working group as a much
improved code first proposal? The potential justification being to avoid
the need for lots trivial drivers where maybe a bit of DSDT interpreted
code does the job better. (Currently I'm not hearing much demand for this
so will probably drop in a future version).
Thanks to all who engaged in the discussion so far.
Jonathan
Jonathan Cameron (5):
memregion: Drop unused IORES_DESC_* parameter from
cpu_cache_invalidate_memregion()
MAINTAINERS: Add Jonathan Cameron to drivers/cache
arm64: Select GENERIC_CPU_CACHE_MAINTENANCE and
ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
acpi: PoC of Cache control via ACPI0019 and _DSM
Hack: Pretend we have PSCI 1.2
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 | 2 +
arch/x86/mm/pat/set_memory.c | 2 +-
drivers/cache/Kconfig | 22 ++++
drivers/cache/Makefile | 3 +
drivers/cache/acpi_cache_control.c | 153 +++++++++++++++++++++++
drivers/cache/hisi_soc_hha.c | 187 +++++++++++++++++++++++++++++
drivers/cxl/core/region.c | 5 +-
drivers/firmware/psci/psci.c | 2 +
drivers/nvdimm/region.c | 2 +-
drivers/nvdimm/region_devs.c | 2 +-
include/linux/cache_coherency.h | 57 +++++++++
include/linux/memregion.h | 10 +-
lib/Kconfig | 3 +
lib/Makefile | 2 +
lib/cache_maint.c | 128 ++++++++++++++++++++
16 files changed, 575 insertions(+), 8 deletions(-)
create mode 100644 drivers/cache/acpi_cache_control.c
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
