On 19/12/14 14:29, Peter Maydell wrote:
> On 19 December 2014 at 14:12, Mark Cave-Ayland
> <mark.cave-ayl...@ilande.co.uk> 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.
