On 09/01/15 13:03, Peter Maydell wrote: > On 9 January 2015 at 12:50, Christoffer Dall > <christoffer.dall@xxxxxxxxxx> wrote: >> On Thu, Jan 08, 2015 at 03:21:50PM +0000, Peter Maydell wrote: >>> If this is the first instruction in the guest (ie we've just >>> (warm) reset the VM and are running the kernel as loaded into the guest >>> by QEMU/kvmtool) then the guest can't have invalidated the icache, >>> and QEMU can't do the invalidate because it doesn't have the vaddr >>> and VMID of the guest. >>> >> The guest must clean its icache before turning on the MMU, no? > > Yes, but to execute the "clean icache" insn inside the guest, > the guest is executing instructions, so we'd better not have > stale info for that code... But we never start a guest with caches on. It has to enable them on its own. >> Whenever we reuse a VMID (rollover), we flush the entire icache for that >> vmid. > > 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). 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
