Re: [Qemu-devel] [PATCH] exec.c: Fix subpage memory access to RAM MemoryRegion

[Avi Kivity <avi@redhat.com>]

On 11/30/2011 06:22 PM, Andreas Färber 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=00000000 size=0x000002 mem=rom name="phdr #0:
> /home/andreas/MCU/RL78/test"
> addr=00000004 size=0x00007c mem=rom name="phdr #1:
> /home/andreas/MCU/RL78/test"
> addr=000000c0 size=0x000004 mem=rom name="phdr #2:
> /home/andreas/MCU/RL78/test"
> addr=000000d8 size=0x000004 mem=rom name="phdr #3:
> /home/andreas/MCU/RL78/test"
> addr=000000dc size=0x00026a mem=rom name="phdr #4:
> /home/andreas/MCU/RL78/test"
> addr=00002000 size=0x0004e4 mem=rom name="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=0x2010)
>     at /home/andreas/QEMU/qemu-rl78/exec.c:3248
> #3  qemu_ram_addr_from_host_nofail (ptr=0x2010)
>     at /home/andreas/QEMU/qemu-rl78/exec.c:3242
> #4  0x00007ffff7f7036d in get_page_addr_code (addr=8208,
> env1=0x7ffff8b04010)
>

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.

-- 
error compiling committee.c: too many arguments to function