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

[Mark Cave-Ayland]

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

> On 19 December 2014 at 14:12, Mark Cave-Ayland
> <address@hidden> wrote:
>> 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.
> 
> I'd check whether the interrupt controller is correctly restoring
> its state...

It's not even getting that far - if I single-step through OpenBIOS then
I can see the first access raising an ISI exception, the entry being
added to the MMU hashtable and then we retry which immediately faults again.

(goes and digs further...)

I think this is a CPUState problem. If I step into
ppc_hash32_htab_lookup() after trying to load an image with -loadvm then
I get this:

Breakpoint 1, ppc_hash32_htab_lookup (env=0x7ffff7fdf260, sr=536871951,
eaddr=4294083148, pte=0x7fffe57ee810) at
/home/build/src/qemu/git/qemu/target-ppc/mmu-hash32.c:338
338     {
(gdb) n
343         vsid = sr & SR32_VSID;
(gdb)
344         pgidx = (eaddr & ~SEGMENT_MASK_256M) >> TARGET_PAGE_BITS;
(gdb)
345         hash = vsid ^ pgidx;
(gdb)
346         ptem = (vsid << 7) | (pgidx >> 10);
(gdb)
352                 env->htab_base, env->htab_mask, hash);
(gdb)
349         qemu_log_mask(CPU_LOG_MMU, "htab_base " TARGET_FMT_plx
(gdb) p/x env->htab_base
$1 = 0x0


It looks like after restoring the CPU state with loadvm env->htab_base
is still at 0x0 rather than its pre-migration value of 0x7e000000.


ATB,

Mark.