Hi Will,
On 2013-08-30 15:30, Will Deacon wrote:
On Fri, Aug 30, 2013 at 03:22:11PM +0100, Marc Zyngier wrote:
On 2013-08-30 15:04, Catalin Marinas wrote:
On Fri, Aug 30, 2013 at 02:21:57PM +0100, Marc Zyngier wrote:
On 2013-08-30 11:44, Anup Patel wrote:
For KVM, we can avoid flushing d-cache to PoC every time in coherent_icache_guest_page() by only doing it when Guest MMU is turned-off. This may reduce the performance penalty.
What about the I and C bits in SCTLR_EL1? Does L3 also honour
these
bits?
I would think so, it probably cares about how the transactions are presented at the bus level by the CPU.
That'd make sense indeed. So we need to track both SCTLR_EL1.{I,C,M} in order to find out whether or not we need to clean the cache.
<horrible hack> Could you use a dummy ATS_* operation, then read the cacheability attributes out of the PAR? </horrible hack>
That'd be doable, and maybe not that expensive (using ATS1, the Stage-1 translation is probably still cached after the translation fault). Actually, I suspect this is more correct than just looking at SCTLR_EL1, as it doesn't assume that the guest uses always cacheable memory when enables the caches.
Shame HPFAR_EL2 doesn't report this information though...
M.