On 09/01/15 15:28, Peter Maydell wrote: > On 9 January 2015 at 14:16, Marc Zyngier <marc.zyngier@xxxxxxx> wrote: >> On 09/01/15 13:03, Peter Maydell wrote: >>> When we reset a cpu by re-calling KVM_ARM_VCPU_INIT, that doesn't >>> mean we get a new VMID for it, though, does it? I thought that >>> what causes the icache flush to happen for the reset guest is >>> that we unmap all of stage 2 and then fault it back in, via >>> this code. That works for PIPT (we flush the range) and for >>> VIPT (we do a full icache flush), but at the moment for VIVT >>> ASID tagged we assume we can do nothing, and I don't think that's >>> right for this case (though it is right for "faulted because >>> page was swapped out" and OK for "page was written by DMA"). >> >> When we reset the guest, we also turn both its Icache off. Before >> turning it back on, the guest has to invalidate it (the ARM ARM doesn't >> seem to define the state of the cache out of reset). > > But implementations are allowed to hit in the cache even > when the cache is disabled. In particular, setting the guest > SCTLR_EL1.I to 0 means "iside accesses are Normal Noncacheable > for stage 1 attributes" and (v8 ARM ARM D3.4.6) these can > be held in the instruction cache. So the guest is required > to do an icache-invalidate for any instructions that it writes > *itself* (or DMAs in) even with the icache off. But it cannot > possibly do so for its own initial startup code, and it must > be the job of KVM to do that for it. (You can think of this as > "the VCPU provided by KVM always invalidates the icache on reset > and does not require an impdef magic cache-init routine as > described by D3.4.4" if you like.) Right. I think I finally see your point. We've been safe so far that no ASID-tagged VIVT icache platform is virtualisation capable, AFAIK. Probably best to just nuke the icache always for non-PIPT caches, then. I'll fold that in when I respin the series. Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
