On Thu, Aug 29, 2013 at 01:31:43PM +0100, Anup Patel wrote: > On Thu, Aug 29, 2013 at 4:22 PM, Catalin Marinas > <catalin.marinas@xxxxxxx> 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 _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
