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... > 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"). -- PMM -- 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
