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

[Marc Zyngier <marc.zyngier@arm.com>]

On Fri, 17 Jul 2015 15:04:27 +0100
Paolo Bonzini <pbonzini@redhat.com> wrote:

> 
> 
> 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.

I've never seen such a corruption - so far.

> > > 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]!

But that's all 32bit code, and your guest was running in 64bit. What
does it look like as A64?

> > 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.

It definitely looks like something tramped on your register file. KVM
doesn't do that at all (we use the whole AArch64 register file
irrespective of the execution state).

Is your UEFI guest 32 or 64bit?

	M.
-- 
Jazz is not dead. It just smells funny.