On Thu, Aug 29, 2013 at 6:23 PM, Catalin Marinas catalin.marinas@arm.com wrote:
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.
It is transparent from CPU perspective. In other words, there is nothing in CPU for controlling/monitoring L3-cache.
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?
Actually, L3-cache monitors the types of read/write generated by CPU (i.e. whether the request is cacheable/non-cacheable or whether the request is due to DC ops to PoC, or ...).
To answer your query, there is no configuration to have L3 caching when accesses are non-cacheable and DC ops to PoC.
Now, back to the idea of outer_cache framework for arm64. Does your CPU have separate instructions for flushing this L3 cache?
No, CPU does not have separate instruction for flushing L3-cache. On the other hand, L3-cache has MMIO registers which can be use to explicitly flush L3-cache.
-- Catalin
--Anup