From mboxrd@z Thu Jan  1 00:00:00 1970
From: mark.rutland@arm.com (Mark Rutland)
Date: Mon, 20 Apr 2015 10:46:44 +0100
Subject: [PATCH] arm64: kill flush_cache_all()
In-Reply-To: <5534C9FF.2030703@arm.com>
References: <1429521875-16893-1-git-send-email-mark.rutland@arm.com>
 <5534C9FF.2030703@arm.com>
Message-ID: <20150420094644.GD15875@leverpostej>
To: linux-arm-kernel@lists.infradead.org
List-Id: linux-arm-kernel.lists.infradead.org

On Mon, Apr 20, 2015 at 10:42:23AM +0100, Marc Zyngier wrote:
> Hi Mark,
> 
> On 20/04/15 10:24, Mark Rutland wrote:
> > The documented semantics of flush_cache_all are not possible to provide
> > for arm64 (short of flushing the entire physical address space by VA),
> > and there are currently no users; KVM uses VA maintenance exclusively,
> > cpu_reset is never called, and the only two users outside of arch code
> > cannot be built for arm64.
> > 
> > While cpu_soft_reset and related functions (which call flush_cache_all)
> > were thought to be useful for kexec, their current implementations only
> > serve to mask bugs. For correctness kexec will need to perform
> > maintenance by VA anyway to account for system caches, line migration,
> > and other subtleties of the cache architecture. As the extent of this
> > cache maintenance will be kexec-specific, it should probably live in the
> > kexec code.
> 
> I assume you mean that kexec will perform VA maintenance as part of its
> private cpu_soft_reset implementation, not that it will reimplement
> flush by S/W as a private method...

Yes; the only subtlety being *what* needs to be flushed will be specific
to kexec. Is there any way I can reword the above to be clearer in that
respect?

> > This patch removes flush_cache_all, and related unused components,
> > preventing further abuse.
> 
> Excellent. I'm pleased we're getting rid of this code which could only
> be (ab)used by broken code. Hopefully this will send a clear message
> that maintenance by VA is the only way we can *safely* deal with caches
> on arm64.

Indeed.

> Acked-by: Marc Zyngier <marc.zyngier@arm.com>

Cheers.

Mark.