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

["Andreas Färber" <afaerber@suse.de>]

Am 29.11.2011 17:46, schrieb Avi Kivity:
> On 11/29/2011 06:19 PM, Andreas Färber wrote:
>> Am 29.11.2011 15:00, schrieb Avi Kivity:
>>> On 11/29/2011 02:47 PM, Andreas Färber wrote:
>>>>>  
>>>>>      addr += mmio->region_offset[idx];
>>>>>      idx = mmio->sub_io_index[idx];
>>>>> +    if (unlikely(idx == IO_MEM_RAM)) {
>>>>> +        ram_addr_t raddr = /*mmio->base |*/ addr;
>>>>> +        void *ptr = qemu_get_ram_ptr(raddr);
>>>>
>>>> ...and/or this seems to lead to "Bad RAM pointer" (or so) when there's
>>>> ELF code loaded into the subpage at that address despite being IO_MEM_RAM?
>>>> (Seen, e.g., if for RL78 I increase the page size from 12 to 16.)
>>>>
>>>
>>> addr is relative to the start of the page, instead of the start of the
>>> region.  You can use mmio->region_offset[idx] to compensate.
>>
>> That's exactly what the first line of the snippet above does, no?
>> (sorry, there's still a confusing comment from an earlier attempt)
>>
> 
> Depends on whether ->region_offset has the right value or not, where's
> the code that adjusts it?  For your case that does f00-fff it should be
> -0xf00 + ram_addr (of the start of the region).

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.

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?

(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)
    at /home/andreas/QEMU/qemu-rl78/exec-all.h:362
#5  tb_find_slow (pc=8208, env=0x7ffff8b04010, cs_base=<optimized out>,
    flags=<optimized out>) at /home/andreas/QEMU/qemu-rl78/cpu-exec.c:95
#6  tb_find_fast (env=0x7ffff8b04010)
    at /home/andreas/QEMU/qemu-rl78/cpu-exec.c:151
#7  cpu_78k0_exec (env=0x7ffff8b04010)
    at /home/andreas/QEMU/qemu-rl78/cpu-exec.c:535
#8  0x00007ffff7f7181c in tcg_cpu_exec (env=0x7ffff8b04010)
    at /home/andreas/QEMU/qemu-rl78/cpus.c:1007
#9  tcg_exec_all () at /home/andreas/QEMU/qemu-rl78/cpus.c:1039
#10 qemu_tcg_cpu_thread_fn (arg=<optimized out>)
    at /home/andreas/QEMU/qemu-rl78/cpus.c:774
#11 0x00007ffff6c8cf05 in start_thread () from /lib64/libpthread.so.0
#12 0x00007ffff621f53d in clone () from /lib64/libc.so.6

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg