Subject: [PATCH] ARM64: KVM: Fix coherent_icache_guest_page() for host with external L3-cache.

From: [email-masked] (Catalin Marinas)
Date: Thu, 29 Aug 2013 13:53:37 +0100

On Thu, Aug 29, 2013 at 01:31:43PM +0100, Anup Patel wrote:
> On Thu, Aug 29, 2013 at 4:22 PM, Catalin Marinas
> <[email-masked]> wrote:
> > On Fri, Aug 16, 2013 at 07:57:55AM +0100, Anup Patel wrote:
> >> The approach of flushing d-cache by set/way upon first run of VCPU will
> >> not work because for set/way operations ARM ARM says: "For set/way
> >> operations, and for All (entire cache) operations, the point is defined to be
> >> to the next level of caching". In other words, set/way operations work upto
> >> point of unification.
> >
> > I don't understand where you got the idea that set/way operations work
> > up to the point of unification. This is incorrect, the set/way
> > operations work on the level of cache specified by bits 3:1 in the
> > register passed to the DC CISW instruction. For your L3 cache, those
> > bits would be 2 (and __flush_dcache_all() implementation does this
> > dynamically).
> 
> The L3-cache is not visible to CPU. It is totally independent and transparent
> to CPU.

OK. But you say that operations like DC CIVAC actually flush the L3? So
I don't see it as completely transparent to the CPU.

Do you have any configuration bits which would make the L3 completely
transparent like always caching even when accesses are non-cacheable and
DC ops to PoC ignoring it?

Now, back to the idea of outer_cache framework for arm64. Does your CPU
have separate instructions for flushing this L3 cache?

-- 
Catalin