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@arm.com 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?