On 1 September 2017 at 18:33, Arnabjyoti Kalita <akal...@cs.stonybrook.edu> wrote: > 1. I start QEMU with *-enable-kvm* option. I then run a workload(a program > from Spec2006) on QEMU. > 2. Immediately after I start running the workload, I open the QEMU monitor > and using "SAVEVM" command I save the QEMU state when the program just > started to execute. > 3. Once the QEMU state is saved, I allow the program to complete. I will > then quit QEMU. > 4. Finally, I will load this snapshot back while starting QEMU - using the > same CPU and machine configurations. This time I do not apply the *-enable-kvm > *option, when loading the snapshot back.
This means you saved the snapshot with KVM, but you reloaded it using TCG (emulation). We don't test that, and it doesn't surprise me very much that it's broken. Figuring out what's going on will probably require some complicated debugging of QEMU internals and what the guest is really doing. You don't say what version of QEMU you're using (or what command line, or what guest CPU architecture), so as a first start you might try the most recent QEMU (2.10) just to check whether you're lucky and the bug is already fixed. It's also a good idea to check whether doing the savevm with TCG (not KVM) means that the loadvm worked, ie confirm that this is a KVM-to-TCG problem rather than just a TCG savevm/loadvm bug. ("Guest just loops around doing nothing" often means "guest OS is in its idle loop because QEMU has lost track of some device or interrutpt controller state that means it should assert an interrupt".) thanks -- PMM