(MIPS) Confusion between virtual and real addresses

[pkooiman]

Trying to do MIPS bare metal simulation here, the code is running at 0x8xxxxxxx. This is the MIPS kseg0 space that bypasses the MMU and maps to 0x00000000 (ie strips the leading 1 in the address). The underlying Qemu handles this correctly, translating from 0x8x.... to 0x0xx, however there is confusion as to the Unicorn memory mapping. When mapping the underlying real address space thus

uc_mem_map(uc, 0x0, RAMSIZE, UC_PROT_ALL);

an unmapped fetch error is generated in helper_le_ld_name() in softmmu_template.h. This is due to a check right at the beginning

MemoryRegion *mr = memory_mapping(uc, addr);

    // memory can be unmapped while reading or fetching`
    if (mr == NULL) {`

memory_mapping() is called here with the virtual adress of 0x8xxxxxxx, and because I mapped only the corresponding real address range, this check fails.

However, when mapping the virtual address range instead:
uc_mem_map(uc, 0x80000000, RAMSIZE, UC_PROT_ALL);

the memory_mapping() call of course works, but then later on after qemu has done the translation to real address space, an error is generated somewhere complaining that the real range at 0x0 is not mapped. The only way out is to map both address ranges.

I may be wrong, but it looks to me like the memory_mapping() call in helper_xx_ld_name() is doomed to fail as soon as any kind of address translation comes into play, because it checks if there is a Unicorn mapping of the virtual address that is passed to the function when it needs to check the translated (physical) address. In the case of MIPS, Unicorn is running Qemu with full r4k softmmu which does not make a lot of sense due to that memory_map() call with the virtual address; but even without MMU emulation, there is still the issue of the various kseg segments that are always translated.

The quickest way to see this problem in action is to change the sample_mips.c sample so it has
#define ADDRESS 0x80010000
which makes it fail with an unmapped fetch error.

[aquynh]

would you please send in a pull request to put a testcase of this issue under either tests/unit/ or tests/regress?

thanks.

[lunixbochs]

what's the solution here? have an api for exposing a mapping at multiple addresses?

[pkooiman]

It's not obvious to me how best to solve this. The underlying Qemu does not need the mapping exposed at multiple addresses, as long as the memory at the corresponding real address is mapped; it is only the Unicorn checks for "is an address actually mapped" that wrongly conclude the memory is not mapped.

Exposing the mapping at multiple adresses would fix that, but it would be nice if that were automatic when, as in the case of MIPS, the architecture always maps a certain memory range to another one (in fact there are 2 such ranges, but for Unicorn it would probably be enough to just disregard the highest 3 address bits).

Perhaps in an ideal world Unicorn would check for a valid mapping only when Qemu comes asking for data (it will do so using the real address). The main problem with that approach is probably that it makes implementing the memory fetch / memory error callbacks a lot more complicated.

[aquynh]

i fixed this issue by redirecting memory in these ranges to physical memory (this is for Mips only). see this commit 3a36e32

now mips_kseg0_1 gives this output:

$ ./tests/regress/mips_kseg0_1
Good, this bug is fixed!

[pkooiman]

Excellent, thanks, closing the issue.