Re: [Qemu-devel] [Qemu-ppc] Unable to loadvm on qemu-system-ppc -M g3beige (keyboard freeze)

[Mark Cave-Ayland]

On 19/12/14 12:29, Peter Maydell wrote:

> On 19 December 2014 at 10:53, Mark Cave-Ayland
> <address@hidden> wrote:
>> It seems that I've misunderstood something mentioned earlier in the
>> thread, i.e. that loadvm also does the create, initialize, realize and
>> reset cycle. At least issuing "loadvm" in the monitor doesn't seem to do
>> that as far as I can see here?
> 
> For monitor "loadvm", we've already done create/initialize/realize
> as part of our initial setup of the VM when we started QEMU.
> reset is done by load_vmstate() calling qemu_system_reset().
> 
> For command line "-loadvm", we do the load_vmstate() after the
> initial reset in vl.c.
> 
> Either way, VM reloading doesn't need to deal with anything that's
> set up in device init/realize as a fixed config, and it doesn't
> need to assert IRQ lines either.

I now have something that nearly works in that I can issue a "savevm"
followed by a "loadvm" in the monitor and be able to resume where I left
off - but only in OpenBIOS. If I boot into an OS and try this then it
doesn't work and the console just sits there frozen.

Also there seems to be a difference between issuing "loadvm" in the
monitor which works, and adding -loadvm to the command line which
completes successfully but still doesn't work as the console remains
frozen, even just in OpenBIOS. This looks similar to trying to load an
image created within an OS as above.

I poked around with gdbstub and the difference with -loadvm on the
command line is that as soon as I step into the next instruction I get a
DSI at the PC address within OpenBIOS space which can't be resolved.

According to "info mtree" the BIOS is present at the physical address,
but it appears that the 1:1 physical to virtual mapping for the BIOS
isn't there (or at least both gdbstub and trying to access the virtual
address where the BIOS is supposed to be located gives a "Cannot access
memory" error).

Could it be that some of the CPU TLB state doesn't get serialized to
disk as part of "savevm" which is causing these immediate faults when
launching with -loadvm?


ATB,

Mark.