From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49700) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZG6Fi-00018S-It for qemu-devel@nongnu.org; Fri, 17 Jul 2015 10:04:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZG6Fc-0002l5-D1 for qemu-devel@nongnu.org; Fri, 17 Jul 2015 10:04:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55972) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZG6Fc-0002kt-5e for qemu-devel@nongnu.org; Fri, 17 Jul 2015 10:04:32 -0400 References: <1437040609-9878-1-git-send-email-pbonzini@redhat.com> <20150716190546.GI29283@redhat.com> <55A8883D.1010207@redhat.com> <55A8CB3E.5090404@redhat.com> <20150717142826.6da03734@arm.com> From: Paolo Bonzini Message-ID: <55A90B6B.9040202@redhat.com> Date: Fri, 17 Jul 2015 16:04:27 +0200 MIME-Version: 1.0 In-Reply-To: <20150717142826.6da03734@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v2 0/3] AioContext: ctx->dispatching is dead, all hail ctx->notify_me List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marc Zyngier Cc: "kwolf@redhat.com" , "lersek@redhat.com" , "Richard W.M. Jones" , "stefanha@redhat.com" , "qemu-devel@nongnu.org" On 17/07/2015 15:28, Marc Zyngier wrote: > >=20 > > 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). >=20 > 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 impleme= nted > 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=3D00000000bf671210 SP=3D00000000c00001f0 > > X00=3D000000000a003e70 X01=3D0000000000000000 X02=3D00000000bf680548 = X03=3D0000000000000030 > > X04=3D00000000bbb5fc18 X05=3D00000000004b7770 X06=3D00000000bf721930 = X07=3D000000000000009a > > X08=3D00000000bf716858 X09=3D0000000000000090 X10=3D0000000000000000 = X11=3D0000000000000046 > > X12=3D00000000a007e03a X13=3D0000000000000000 X14=3D0000000000000000 = X15=3D0000000000000000 > > X16=3D00000000bf716df0 X17=3D0000000000000000 X18=3D0000000000000000 = X19=3D00000000bf6f5f18 > > X20=3D0000000000000000 X21=3D0000000000000000 X22=3D0000000000000000 = X23=3D0000000000000000 > > X24=3D0000000000000000 X25=3D0000000000000000 X26=3D0000000000000000 = X27=3D0000000000000000 > > X28=3D0000000000000000 X29=3D0000000000000000 X30=3D0000000000000000 = PSTATE=3D60000305 (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