From: <dan.j.williams@intel.com>
To: Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>, <james.morse@arm.com>,
<linux-cxl@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-acpi@vger.kernel.org>, <linux-arch@vger.kernel.org>,
<linux-mm@kvack.org>, <gregkh@linuxfoundation.org>,
Will Deacon <will@kernel.org>,
Dan Williams <dan.j.williams@intel.com>,
Davidlohr Bueso <dave@stgolabs.net>
Cc: Yicong Yang <yangyicong@huawei.com>, <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>, H Peter Anvin <hpa@zytor.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [PATCH v2 2/8] generic: Support ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
Date: Wed, 9 Jul 2025 22:57:37 -0700 [thread overview]
Message-ID: <686f565121ea5_1d3d100ee@dwillia2-xfh.jf.intel.com.notmuch> (raw)
In-Reply-To: <20250624154805.66985-3-Jonathan.Cameron@huawei.com>
Jonathan Cameron wrote:
> From: Yicong Yang <yangyicong@hisilicon.com>
>
> ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION provides the mechanism for
> invalidate certain memory regions in a cache-incoherent manner.
> Currently is used by NVIDMM adn CXL memory. This is mainly done
> by the system component and is implementation define per spec.
> Provides a method for the platforms register their own invalidate
> method and implement ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION.
Please run spell-check on changelogs.
>
> Architectures can opt in for this support via
> CONFIG_GENERIC_CPU_CACHE_INVALIDATE_MEMREGION.
>
> Signed-off-by: Yicong Yang <yangyicong@hisilicon.com>
> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
> ---
> drivers/base/Kconfig | 3 +++
> drivers/base/Makefile | 1 +
> drivers/base/cache.c | 46 ++++++++++++++++++++++++++++++++
I do not understand what any of this has to do with drivers/base/.
See existing cache management memcpy infrastructure in lib/Kconfig.
> include/asm-generic/cacheflush.h | 12 +++++++++
> 4 files changed, 62 insertions(+)
>
> diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
> index 064eb52ff7e2..cc6df87a0a96 100644
> --- a/drivers/base/Kconfig
> +++ b/drivers/base/Kconfig
> @@ -181,6 +181,9 @@ config SYS_HYPERVISOR
> bool
> default n
>
> +config GENERIC_CPU_CACHE_INVALIDATE_MEMREGION
> + bool
> +
> config GENERIC_CPU_DEVICES
> bool
> default n
> diff --git a/drivers/base/Makefile b/drivers/base/Makefile
> index 8074a10183dc..0fbfa4300b98 100644
> --- a/drivers/base/Makefile
> +++ b/drivers/base/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_DEV_COREDUMP) += devcoredump.o
> obj-$(CONFIG_GENERIC_MSI_IRQ) += platform-msi.o
> obj-$(CONFIG_GENERIC_ARCH_TOPOLOGY) += arch_topology.o
> obj-$(CONFIG_GENERIC_ARCH_NUMA) += arch_numa.o
> +obj-$(CONFIG_GENERIC_CPU_CACHE_INVALIDATE_MEMREGION) += cache.o
> obj-$(CONFIG_ACPI) += physical_location.o
>
> obj-y += test/
> diff --git a/drivers/base/cache.c b/drivers/base/cache.c
> new file mode 100644
> index 000000000000..8d351657bbef
> --- /dev/null
> +++ b/drivers/base/cache.c
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Generic support for CPU Cache Invalidate Memregion
> + */
> +
> +#include <linux/spinlock.h>
> +#include <linux/export.h>
> +#include <asm/cacheflush.h>
> +
> +
> +static const struct system_cache_flush_method *scfm_data;
> +DEFINE_SPINLOCK(scfm_lock);
> +
> +void generic_set_sys_cache_flush_method(const struct system_cache_flush_method *method)
> +{
> + guard(spinlock_irqsave)(&scfm_lock);
> + if (scfm_data || !method || !method->invalidate_memregion)
> + return;
> +
> + scfm_data = method;
The lock looks unnecessary here, this is just atomic_cmpxchg().
> +}
> +EXPORT_SYMBOL_GPL(generic_set_sys_cache_flush_method);
> +
> +void generic_clr_sys_cache_flush_method(const struct system_cache_flush_method *method)
> +{
> + guard(spinlock_irqsave)(&scfm_lock);
> + if (scfm_data && scfm_data == method)
> + scfm_data = NULL;
Same here, but really what is missing is a description of the locking
requirements of cpu_cache_invalidate_memregion().
> +}
> +
> +int cpu_cache_invalidate_memregion(int res_desc, phys_addr_t start, size_t len)
> +{
> + guard(spinlock_irqsave)(&scfm_lock);
> + if (!scfm_data)
> + return -EOPNOTSUPP;
> +
> + return scfm_data->invalidate_memregion(res_desc, start, len);
Is it really the case that you need to disable interrupts during cache
operations? For potentially flushing 10s to 100s of gigabytes, is it
really the case that all archs can support holding interrupts off for
that event?
A read lock (rcu or rwsem) seems sufficient to maintain registration
until the invalidate operation completes.
If an arch does need to disable interrupts while it manages caches that
does not feel like something that should be enforced for everyone at
this top-level entry point.
> +}
> +EXPORT_SYMBOL_NS_GPL(cpu_cache_invalidate_memregion, "DEVMEM");
> +
> +bool cpu_cache_has_invalidate_memregion(void)
> +{
> + guard(spinlock_irqsave)(&scfm_lock);
> + return !!scfm_data;
Lock seems pointless here.
More concerning is this diverges from the original intent of this
function which was to disable physical address space manipulation from
virtual environments.
Now, different archs may have reason to diverge here but the fact that
the API requirements are non-obvious points at a minimum to missing
documentation if not missing cross-arch consensus.
> +}
> +EXPORT_SYMBOL_NS_GPL(cpu_cache_has_invalidate_memregion, "DEVMEM");
> diff --git a/include/asm-generic/cacheflush.h b/include/asm-generic/cacheflush.h
> index 7ee8a179d103..87e64295561e 100644
> --- a/include/asm-generic/cacheflush.h
> +++ b/include/asm-generic/cacheflush.h
> @@ -124,4 +124,16 @@ static inline void flush_cache_vunmap(unsigned long start, unsigned long end)
> } while (0)
> #endif
>
> +#ifdef CONFIG_GENERIC_CPU_CACHE_INVALIDATE_MEMREGION
> +
> +struct system_cache_flush_method {
> + int (*invalidate_memregion)(int res_desc,
> + phys_addr_t start, size_t len);
> +};
The whole point of ARCH_HAS facilities is to resolve symbols like this
at compile time. Why does this need a indirect function call at all?
next prev parent reply other threads:[~2025-07-10 5:58 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-24 15:47 [PATCH v2 0/8] Cache coherency management subsystem Jonathan Cameron
2025-06-24 15:47 ` [PATCH v2 1/8] memregion: Support fine grained invalidate by cpu_cache_invalidate_memregion() Jonathan Cameron
2025-07-09 19:46 ` Davidlohr Bueso
2025-07-09 22:31 ` dan.j.williams
2025-07-11 11:54 ` Jonathan Cameron
2025-06-24 15:47 ` [PATCH v2 2/8] generic: Support ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION Jonathan Cameron
2025-06-24 16:16 ` Greg KH
2025-06-25 16:46 ` Jonathan Cameron
2025-07-10 5:57 ` dan.j.williams [this message]
2025-07-10 6:01 ` H. Peter Anvin
2025-07-11 11:53 ` Jonathan Cameron
2025-07-11 11:52 ` Jonathan Cameron
2025-08-07 16:07 ` Jonathan Cameron
2025-06-24 15:47 ` [PATCH v2 3/8] cache: coherency core registration and instance handling Jonathan Cameron
2025-06-24 15:48 ` [PATCH v2 4/8] MAINTAINERS: Add Jonathan Cameron to drivers/cache Jonathan Cameron
2025-06-24 15:48 ` [PATCH v2 5/8] arm64: Select GENERIC_CPU_CACHE_INVALIDATE_MEMREGION Jonathan Cameron
2025-06-25 16:21 ` kernel test robot
2025-06-28 7:10 ` kernel test robot
2025-06-24 15:48 ` [PATCH v2 6/8] cache: Support cache maintenance for HiSilicon SoC Hydra Home Agent Jonathan Cameron
2025-06-24 17:18 ` Randy Dunlap
2025-06-24 15:48 ` [RFC v2 7/8] acpi: PoC of Cache control via ACPI0019 and _DSM Jonathan Cameron
2025-06-24 15:48 ` [PATCH v2 8/8] Hack: Pretend we have PSCI 1.2 Jonathan Cameron
2025-06-25 8:52 ` [PATCH v2 0/8] Cache coherency management subsystem Peter Zijlstra
2025-06-25 9:12 ` H. Peter Anvin
2025-06-25 9:31 ` Peter Zijlstra
2025-06-25 17:03 ` Jonathan Cameron
2025-06-26 9:55 ` Jonathan Cameron
2025-07-10 5:32 ` dan.j.williams
2025-07-10 10:59 ` Peter Zijlstra
2025-07-10 18:36 ` dan.j.williams
2025-07-10 5:22 ` dan.j.williams
2025-07-10 5:31 ` H. Peter Anvin
2025-07-10 10:56 ` Peter Zijlstra
2025-07-10 18:45 ` dan.j.williams
2025-07-10 18:55 ` H. Peter Anvin
2025-07-10 19:11 ` dan.j.williams
2025-07-10 19:16 ` H. Peter Anvin
2025-07-09 19:53 ` Davidlohr Bueso
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=686f565121ea5_1d3d100ee@dwillia2-xfh.jf.intel.com.notmuch \
--to=dan.j.williams@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=dave@stgolabs.net \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=james.morse@arm.com \
--cc=linux-acpi@vger.kernel.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 \
--cc=yangyicong@huawei.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;
as well as URLs for NNTP newsgroup(s).