Hi Peter,
Thank you for your answer.
I am sorry that I did not provide all the other details that you requested.
Basically, I am using a Linux-4.11.3(Ubuntu 17.04) on the host and
Linux-4.4.0-62-generic(Ubuntu 16.04) on the guest. The machine is x86_64
architecture. I am currently using QEMU version 2.8.0.
I just tested the savevm and loadvm both with TCG. It works. So it is
definitely not a TCG-to-TCG bug. It clearly looks like a KVM-to-TCG bug.
I am using the below command to start QEMU for SAVEVM(with KVM) :-
qemu-system-x86_64 -m 10G -machine pc-i440fx-2.5 -enable-kvm -cpu
qemu64,-kvmclock -drive file=ubuntu16.04.server.qcow2,format=qcow2
Once I perform the savevm, I will then do a LOADVM using the below
command(with TCG) :-
qemu-system-x86_64 -m 10G -machine pc-i440fx-2.5 -drive
file=ubuntu16.04.server.qcow2,format=qcow2 -loadvm fifteenth-snapshot
After further analysis, with the help of the QEMU monitor, I see that QEMU
is hanging at a kernel address/instruction :-
0xffffffff810645d6 : pop %rbp (This is not the first instruction
executed when QEMU is loaded)
Let me know if this further clarifies my situation to you. I will try this
experiment with the new QEMU version 2.10 as well. I will be grateful if
you can provide me with some more details on the root cause of this issue.
Best Regards,
Arnab
On Mon, Sep 4, 2017 at 4:58 AM, Peter Maydell <peter.mayd...@linaro.org>
wrote:
> 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
>
