On Mon, Dec 01, 2014 at 05:57:53PM +0000, Peter Maydell wrote: > On 27 November 2014 at 23:10, Peter Maydell <peter.maydell@xxxxxxxxxx> wrote: > > It seems odd to have this unmap happen on attempted system reset/powerdown, > > not on cpu init/start. > > Here's a concrete case that I think requires the unmap to be > done on cpu init: > * start a VM and run it for a bit > * from the QEMU monitor, use "loadvm" to load a VM snapshot > > This will cause QEMU to do a system reset (including calling > VCPU_INIT to reset the CPUs), load the contents of guest > RAM from the snapshot, set guest CPU registers with a pile > of SET_ONE_REG calls, and then KVM_RUN to start the VM. > > If we don't unmap stage2 on vcpu init, then what in this > sequence causes the icaches to be flushed so we execute > the newly loaded ram contents rather than stale data > from the first VM run? > You're absolutely right that it makes more sense to stick it in vcpu_init. I put it only in the shutdown event handler for debugging and forgot that was what I was doing :) The only down-side is that we'll be trying to free memory that was never mapped on initial startup, but it's not in the critical path and we could add an explicit check to early-out if the vcpu has never been run, which may increase code readibility too (we already have that flag I belive). -Christoffer -- 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
