From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41686) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RW2sn-0004Zv-Fo for qemu-devel@nongnu.org; Thu, 01 Dec 2011 04:24:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RW2sh-0007D2-M7 for qemu-devel@nongnu.org; Thu, 01 Dec 2011 04:24:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1028) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RW2sh-0007Cn-ET for qemu-devel@nongnu.org; Thu, 01 Dec 2011 04:24:39 -0500 Message-ID: <4ED747D3.6070305@redhat.com> Date: Thu, 01 Dec 2011 11:24:35 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1322492805-5530-1-git-send-email-afaerber@suse.de> <4ED4D446.3010508@suse.de> <4ED4E56C.9090507@redhat.com> <4ED505FE.2090808@suse.de> <4ED50C73.8090507@redhat.com> <4ED65852.9080005@suse.de> In-Reply-To: <4ED65852.9080005@suse.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] exec.c: Fix subpage memory access to RAM MemoryRegion List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= Cc: Peter Maydell , qemu-devel@nongnu.org On 11/30/2011 06:22 PM, Andreas F=C3=A4rber wrote: > The problem is not with the 0xfff00 region, that one works fine with 12 > and 16 bit pages so far. > > What I'm seeing is a crash of the very first TB at PC 0x02010, which is > in a 4K RAM region from 0x0 on, with 16 bit pages. Also happens with v2. Executing out of subpage RAM is probably unique enough to have its own set of weird and wonderful bugs. Since it's the very first TB, you could simply add tons of instrumentation and just follow the guest code and see what it does. > It's similar to my original problem of being unable to read the reset > vector, where I couldn't use the regular memory read functions but had > to use rom_ptr(), as Peter pointed out in > target-arm/helper.c:cpu_reset(). Apparently I'll need to add some check > for handling ROM, but on what condition and where? Don't really > understand why loading ELF code into a RAM area creates these weird ROM > areas... Is this a legacy thing, as it's not shown in info mtree? Everything should be seen in 'info mtree', at least for everything that's been converted. You could try the memory/master branch where this is true. Did you add roms yourself? > > (qemu) info roms > addr=3D00000000 size=3D0x000002 mem=3Drom name=3D"phdr #0: > /home/andreas/MCU/RL78/test" > addr=3D00000004 size=3D0x00007c mem=3Drom name=3D"phdr #1: > /home/andreas/MCU/RL78/test" > addr=3D000000c0 size=3D0x000004 mem=3Drom name=3D"phdr #2: > /home/andreas/MCU/RL78/test" > addr=3D000000d8 size=3D0x000004 mem=3Drom name=3D"phdr #3: > /home/andreas/MCU/RL78/test" > addr=3D000000dc size=3D0x00026a mem=3Drom name=3D"phdr #4: > /home/andreas/MCU/RL78/test" > addr=3D00002000 size=3D0x0004e4 mem=3Drom name=3D"phdr #5: > /home/andreas/MCU/RL78/test" > (qemu) cont > > Bad ram pointer 0x2010 > > Program received signal SIGABRT, Aborted. > [Switching to Thread 0x7ffff5504700 (LWP 6484)] > 0x00007ffff617ad95 in raise () from /lib64/libc.so.6 > (gdb) bt > #0 0x00007ffff617ad95 in raise () from /lib64/libc.so.6 > #1 0x00007ffff617c2ab in abort () from /lib64/libc.so.6 > #2 0x00007ffff7f76928 in qemu_ram_addr_from_host_nofail (ptr=3D0x2010) > at /home/andreas/QEMU/qemu-rl78/exec.c:3248 > #3 qemu_ram_addr_from_host_nofail (ptr=3D0x2010) > at /home/andreas/QEMU/qemu-rl78/exec.c:3242 > #4 0x00007ffff7f7036d in get_page_addr_code (addr=3D8208, > env1=3D0x7ffff8b04010) > This function tries to translate a virtual guest address of a page into a ram address, but that doesn't work for subpage. if (pd > IO_MEM_ROM && !(pd & IO_MEM_ROMD)) { #if defined(TARGET_ALPHA) || defined(TARGET_MIPS) || defined(TARGET_SPARC= ) cpu_unassigned_access(env1, addr, 0, 1, 0, 4); #else cpu_abort(env1, "Trying to execute code outside RAM or ROM at 0x" TARGET_FMT_lx "\n", addr); #endif You're clearly in RAM or ROM, but the subpage code confuses qemu. It's not going to be easy to unconfuse it. --=20 error compiling committee.c: too many arguments to function