From mboxrd@z Thu Jan 1 00:00:00 1970 From: catalin.marinas@arm.com (Catalin Marinas) Date: Thu, 29 Aug 2013 13:53:37 +0100 Subject: [PATCH] ARM64: KVM: Fix coherent_icache_guest_page() for host with external L3-cache. In-Reply-To: References: <3ebe469fcf451cc7396dd2a5d3f01272@www.loen.fr> <747a0675165da4ef147bbda4e140549b@www.loen.fr> <5935339137684ecf90dd484cc5739548@www.loen.fr> <20130815165344.GA3853@cbox> <20130829105235.GC13704@arm.com> Message-ID: <20130829125337.GG13704@arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Aug 29, 2013 at 01:31:43PM +0100, Anup Patel wrote: > On Thu, Aug 29, 2013 at 4:22 PM, Catalin Marinas > 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