Hello, I am working on save/restore code (independent of Qemu or KVM tools) and am having trouble doing 'the right thing' with KVM it seems. I do have trouble finding good documentation on specifically save or restore (besides the description of IOCTLs) and there is a high chance I am doing something goofy here. The way I am save/restoring is simply saving the state I get through the different KVM IOCTLs and dumping it back on restore. The exception is restoring of the MSRs, where I first get the list, then get the MSRS and save/restore only those that were filled in by KVM. The restore order is the following: first restore memory, then KVM_SET_REGS KVM_SET_FPU KVM_SET_SREGS KVM_SET_MSRS KVM_SET_MPSTATE KVM_SET_LAPIC some user mode devices and then KVM_SET_PIT KVM_SET_IRQCHIP (3 times, for MASTER, SLAVE and IOAPIC) I am running different tests to test the save/restore code. One test for example will compile the linux kernel within the guest while the VM is saved, destroyed, re-create and finally restored & resumed during compilation (every 10 seconds) on the same physical machine. The behavior I get is different depending on KVM version and CPU. Running with kvm-84 gives only sporadic failures, maybe every thousand restores a double fault in the guest. Running with a 2.6.34 kernel gives an 'immediate' double fault in the guest. The guest does resume work as megabytes of guest data get modified before the double fault but eventually the guest crashes - and always it seems in the page fault handler. This is pretty much 100% reproduceable even with a 'workload' that simply does a "sleep 1d" in a shell script. On Intel CPUs though I get a VMX_INVALID_GUEST_STATE error. The guest does not run - which tells me I am doing something wrong here. Assuming that the KVM versions work fine - what state that comes from KVM through one of the KVM_GET_* IOCTLs has to be modified/sanitized on restore? Thanks, Frank. -- 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
