[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] Unable to loadvm on qemu-system-ppc -M g3bei

From: Mark Cave-Ayland
Subject: Re: [Qemu-ppc] [Qemu-devel] Unable to loadvm on qemu-system-ppc -M g3beige (keyboard freeze)
Date: Fri, 19 Dec 2014 16:15:26 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.3.0

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
338     {
(gdb) n
343         vsid = sr & SR32_VSID;
344         pgidx = (eaddr & ~SEGMENT_MASK_256M) >> TARGET_PAGE_BITS;
345         hash = vsid ^ pgidx;
346         ptem = (vsid << 7) | (pgidx >> 10);
352                 env->htab_base, env->htab_mask, hash);
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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]