linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <Jonathan.Cameron@huawei.com>
To: Yicong Yang <yangyicong@huawei.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	<yangyicong@hisilicon.com>, <linux-cxl@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>, <james.morse@arm.com>,
	<conor@kernel.org>, <linux-acpi@vger.kernel.org>,
	<linux-arch@vger.kernel.org>, <linuxarm@huawei.com>,
	Yushan Wang <wangyushan12@huawei.com>, <linux-mm@kvack.org>,
	<gregkh@linuxfoundation.org>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Will Deacon <will@kernel.org>,
	"Dan Williams" <dan.j.williams@intel.com>
Subject: Re: [RFC PATCH 2/6] arm64: Support ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
Date: Fri, 13 Jun 2025 18:14:34 +0100	[thread overview]
Message-ID: <20250613181434.00004e7e@huawei.com> (raw)
In-Reply-To: <64ae0e68-b025-4a33-9389-5393ee887fb4@huawei.com>

On Sat, 29 Mar 2025 15:14:14 +0800
Yicong Yang <yangyicong@huawei.com> wrote:

> On 2025/3/29 2:22, Catalin Marinas wrote:
> > On Thu, Mar 20, 2025 at 05:41:14PM +0000, Jonathan Cameron wrote:  
> >> +struct system_cache_flush_method {
> >> +	int (*invalidate_memregion)(int res_desc,
> >> +				    phys_addr_t start, size_t len);
> >> +};  
> > [...]  
> >> +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);
> >> +}  
> > 
> > WBINVD on x86 deals with the CPU caches as well. Even the API naming in
> > Linux implies CPU caches. IIUC, devices registering to the above on Arm
> > SoCs can only deal with system caches. Is it sufficient?
> >   
> 
> The device driver who register this method should handle this. If the
> hardware support maintaining the coherency among the system, for example
> on system cache invalidation the hardware is also able to invalidate the
> involved cachelines on all the subordinate caches (L1/L2/etc, by back
> invalidate snoop or other ways), then software don't need to invalidate
> the non-system cache explicitly. Otherwise the driver need to explicitly
> invalidate the non-system cache explicitly in their
> scfm_data::invalidate_memregion() method. Here in the generally code we
> simply don't know the capability of the hardware.

Coming to this a little late.  It would definitely be helpful to understand
whether other hardware implementations where this is relevant (e.g. CXL
capable systems) do require explicit flushes of the caches nearer the
CPU and any dance that they need in that case to ensure no race conditions
leave stale lines.

The PSCI spec (that never was) did allow for reporting that it was necessary
to stop all traffic prior to flushes, but that is crazy to support and
someone built the wrong system if they need to do that under even
vaguely normal software flows.

Jonathan
 
> 
> Thanks.
> 



  reply	other threads:[~2025-06-13 17:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-20 17:41 [RFC PATCH 0/6] Cache coherency management subsystem Jonathan Cameron
2025-03-20 17:41 ` [RFC PATCH 1/6] memregion: Support fine grained invalidate by cpu_cache_invalidate_memregion() Jonathan Cameron
2025-03-20 17:41 ` [RFC PATCH 2/6] arm64: Support ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION Jonathan Cameron
2025-03-28 18:22   ` Catalin Marinas
2025-03-29  7:14     ` Yicong Yang
2025-06-13 17:14       ` Jonathan Cameron [this message]
2025-03-20 17:41 ` [RFC PATCH 3/6] cache: coherency device class Jonathan Cameron
2025-03-20 21:12   ` Greg KH
2025-03-21  9:38     ` Jonathan Cameron
2025-03-20 17:41 ` [RFC PATCH 4/6] cache: Support cache maintenance for HiSilicon SoC Hydra Home Agent Jonathan Cameron
2025-03-20 17:41 ` [RFC PATCH 5/6] acpi: PoC of Cache control via ACPI0019 and _DSM Jonathan Cameron
2025-03-20 17:41 ` [RFC PATCH 6/6] Hack: Pretend we have PSCI 1.2 Jonathan Cameron
2025-03-21 22:32 ` [RFC PATCH 0/6] Cache coherency management subsystem Conor Dooley
2025-03-24 12:00   ` Jonathan Cameron

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=20250613181434.00004e7e@huawei.com \
    --to=jonathan.cameron@huawei.com \
    --cc=catalin.marinas@arm.com \
    --cc=conor@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --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=mark.rutland@arm.com \
    --cc=wangyushan12@huawei.com \
    --cc=will@kernel.org \
    --cc=yangyicong@hisilicon.com \
    --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