From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:32815) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SR22z-0008F0-Pq for qemu-devel@nongnu.org; Sun, 06 May 2012 10:02:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SR22x-0004MI-OW for qemu-devel@nongnu.org; Sun, 06 May 2012 10:02:49 -0400 Received: from cantor2.suse.de ([195.135.220.15]:51420 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SR22x-0004Lu-F6 for qemu-devel@nongnu.org; Sun, 06 May 2012 10:02:47 -0400 Message-ID: <4FA68483.8090805@suse.de> Date: Sun, 06 May 2012 16:02:43 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <4FA54951.90908@suse.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] sparc-softmmu uninitialized memory read? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Mark Cave-Ayland , Alexander Graf , qemu-devel Am 06.05.2012 13:32, schrieb Blue Swirl: > On Sat, May 5, 2012 at 3:37 PM, Andreas F=C3=A4rber = wrote: >> Hello Blue, >> >> Testing a potential AREG0 fix for ppc host by malc I got an error >> running `./sparc-softmmu/sparc-softmmu` (same with CD/kernel): >> >> qemu: fatal: Trap 0x07 while interrupts disabled, Error state >> pc: 00005e0c npc: 00005e10 >> General Registers: >> %g0-7: 00000000 00000001 babababa 00000000 00000020 07ffff08 07ffe000 >> babababa >> >> Current Register Window: >> %o0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >> 00000000 >> %l0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >> 00000000 >> %i0-7: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >> 00000000 >> >> Floating Point Registers: >> %f00: 0000000000000000 0000000000000000 0000000000000000 0000000000000= 000 >> %f08: 0000000000000000 0000000000000000 0000000000000000 0000000000000= 000 >> %f16: 0000000000000000 0000000000000000 0000000000000000 0000000000000= 000 >> %f24: 0000000000000000 0000000000000000 0000000000000000 0000000000000= 000 >> psr: 048000c0 (icc: N--- SPE: SP-) wim: 00000001 >> fsr: 00000000 y: 00000020 >> Abgebrochen >> >> The 0xbabababa in %g2 and %g7 is a signature I've seen in uninitialize= d >> memory on openSUSE 12.1 Betas. So I ran valgrind, and the following >> caught my eye on both ppc and x86_64: >> >> =3D=3D18801=3D=3D Command: ./sparc-softmmu/qemu-system-sparc >> =3D=3D18801=3D=3D >> =3D=3D18801=3D=3D Thread 2: >> =3D=3D18801=3D=3D Conditional jump or move depends on uninitialised va= lue(s) >> =3D=3D18801=3D=3D at 0x25C5AF: compute_all_logic (cc_helper.c:37) >> =3D=3D18801=3D=3D by 0x25C648: helper_compute_psr (cc_helper.c:470) >> =3D=3D18801=3D=3D by 0x8CD0981: ??? >> =3D=3D18801=3D=3D Uninitialised value was created by a heap allocatio= n >> =3D=3D18801=3D=3D at 0x4C27CE8: memalign (in >> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) >> =3D=3D18801=3D=3D by 0x4C27D97: posix_memalign (in >> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) >> =3D=3D18801=3D=3D by 0x1F2101: qemu_memalign (oslib-posix.c:93) >> =3D=3D18801=3D=3D by 0x1F21A9: qemu_vmalloc (oslib-posix.c:126) >> =3D=3D18801=3D=3D by 0x2665F6: qemu_ram_alloc_from_ptr (exec.c:2647= ) >> =3D=3D18801=3D=3D by 0x286D76: memory_region_init_ram (memory.c:954= ) >> =3D=3D18801=3D=3D by 0x297FFD: ram_init1 (sun4m.c:757) >> =3D=3D18801=3D=3D by 0x204DAE: qdev_init (qdev.c:151) >> =3D=3D18801=3D=3D by 0x204EEC: qdev_init_nofail (qdev.c:258) >> =3D=3D18801=3D=3D by 0x298845: ram_init.constprop.7 (sun4m.c:783) >> =3D=3D18801=3D=3D by 0x298980: sun4m_hw_init (sun4m.c:862) >> =3D=3D18801=3D=3D by 0x2994A2: ss5_init (sun4m.c:1289) >> >> This is at 8f473dd104f0937ce98523fa6f9de0bd845aebbe, and cc_helper.c:3= 7 >> is int32_t dst argument of get_NZ_icc(), which is always called with >> CC_DST, i.e. env->cc_dst. >> >> This seems to indicate that a read from uninitialized memory occurred, >> from which cc_dst is being initialized? >=20 > This should happen in target-sparc/cpu.c:45 > memset(env, 0, offsetof(CPUSPARCState, breakpoints)); >=20 > cc_dst is between structure start and CPU_COMMON. >=20 > 89aaf60dedbe0e6415acfe816e02b538e5c54e68 fixed a bug relating to reset = recently. The still-current master commit above includes that fix though, and that's no explanation for the uninitialized memory stemming from sun4m RAM as opposed to QOM object_new(). Somewhere a read is happening, possibly in OpenBIOS, from uninitialized memory that is then stored into the CPUSPARCState after that has been zero-initialized, IIUC. My issue here is that sparc64 boots HelenOS fine up until it's trying to load the kernel (identical to x86_64 host) but sparc32 exits really early on ppc. It might well be that there's a bug hidden in malc's TCG patch that's causing the fatal error state, but the uninitialized memory report is on both TCG hosts, so unlikely TCG-related. /-F >> Any idea where that could originate from or how to further debug? >> It doesn't seem to be caused by the >> 7d21dcc84b8c07918124a9c0708694d2fb013f65 OpenBIOS r1056 update. >> >> Regards, >> >> Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg