Re: [Qemu-devel] [PATCH v2 0/3] AioContext: ctx->dispatching is dead, all hail ctx->notify_me

[Paolo Bonzini]

On 17/07/2015 15:28, Marc Zyngier wrote:
> > 
> > Marc, does it ring any bell?
> Well, this is an example of a guest accessing non-memory using an
> instruction that we cannot safely emulate - not an IO accessor (load
> multiple, for example).
> 
> In this case, we kill the guest (we could as well inject a fault).

Yup, I later found this in the dmesg:

[1875219.903969] kvm [14843]: load/store instruction decoding not implemented

> This vcpu seems to be accessing 0x9000018 (the mmio structure points
> there), but I can't immediately relate it to the content of the
> registers.

0x9000018 is the pl011, which makes some sense.

Have you ever seen a corrupted register dump?  The guest RAM goes
from 0x40000000 to 0xbfffffff, so SP is pointing outside memory.

> > PC=00000000bf671210  SP=00000000c00001f0
> > X00=000000000a003e70 X01=0000000000000000 X02=00000000bf680548 
> > X03=0000000000000030
> > X04=00000000bbb5fc18 X05=00000000004b7770 X06=00000000bf721930 
> > X07=000000000000009a
> > X08=00000000bf716858 X09=0000000000000090 X10=0000000000000000 
> > X11=0000000000000046
> > X12=00000000a007e03a X13=0000000000000000 X14=0000000000000000 
> > X15=0000000000000000
> > X16=00000000bf716df0 X17=0000000000000000 X18=0000000000000000 
> > X19=00000000bf6f5f18
> > X20=0000000000000000 X21=0000000000000000 X22=0000000000000000 
> > X23=0000000000000000
> > X24=0000000000000000 X25=0000000000000000 X26=0000000000000000 
> > X27=0000000000000000
> > X28=0000000000000000 X29=0000000000000000 X30=0000000000000000 
> > PSTATE=60000305 (flags -ZC-)

If the register dump is not corrupted, execution went in the weeds...
I don't have the guest anymore but it's just firmware so the memory
contents are well reproducible:

0x00000000bf671200:  a97d6ffa      ldmdbge      sp!, {r1, r3, r4, r5, r6, r7, 
r8, r9, sl, fp, sp, lr}^
0x00000000bf671204:  a97e77fc      ldmdbge      lr!, {r2, r3, r4, r5, r6, r7, 
r8, r9, sl, ip, sp, lr}^
0x00000000bf671208:  f85f03fe      undefined instruction 0xf85f03fe
0x00000000bf67120c:  910803ff      strdls       r0, [r8, -pc]
0x00000000bf671210:  ad7007e0      ldclge       7, cr0, [r0, #-896]!
0x00000000bf671214:  ad710fe2      ldclge       15, cr0, [r1, #-904]!
0x00000000bf671218:  ad7217e4      ldclge       7, cr1, [r2, #-912]!
0x00000000bf67121c:  ad731fe6      ldclge       15, cr1, [r3, #-920]!
0x00000000bf671220:  ad7427e8      ldclge       7, cr2, [r4, #-928]!
0x00000000bf671224:  ad752fea      ldclge       15, cr2, [r5, #-936]!

> What looks a bit weird is that all the registers are clamped to 32bit,
> but the PSTATE indicates it is running in 64bit (EL1h, which makes the
> PC being utterly wrong).

The PC can be okay since UEFI code doesn't really use virtual addressing,
but the other registers are weird indeed.

> What are you running there?

Just firmware.  It's a UEFI reboot loop (as soon as you get to the
UEFI shell QEMU exits and the script starts a new one).

The kernel is an old 3.19 one, I'll upgrade and retest.

Paolo