Re: TARGET_SYS_HEAPINFO and Cortex-A15 memory map

[Peter Maydell]

On Fri, 3 Jun 2022 at 07:17, Liviu Ionescu <ilg@livius.net> wrote:
> > On 2 Jun 2022, at 21:36, Liviu Ionescu <ilg@livius.net> wrote:
> >
> > ... SYS_HEAPINFO...
> >
> > 0x04000000 - heap base
> > 0x08000000 - heap limit
> > 0x08000000 - stack base
> > 0x0 - stack limit
>
> For Cortex-A72 I see similar values:
>
> 0x44000000
> 0x48000000
> 0x48000000
> 0x40000000
>
> just that in this case the memory is writable, and the startup proceeds as 
> expected.
>
> Any idea why in the Cortex-A15 case the memory below 0x08000000 is not 
> writable?

Sorry I didn't get back to this before -- I marked it in my email client
but then forgot about it :-(

Anyway, the memory map for the 'virt' board doesn't change for the a72
versus the a15. In both cases, the memory from 0x0 to 0x08000000
is the flash memory. So QEMU is incorrect to have reported that as
the place to put the heap in SYS_HEAPINFO.

I'm not sure why the A72 gives different results, but the heuristic
that tries to figure out where the heap goes is basically trying to
do "find the biggest lump of memory which doesn't have some bit of
the guest code in it", so it's going to be sensitive to things like
just how big that guest binary happens to be and where it's loaded.
Perhaps that is why it's ended up different.

I suspect the fix to this bug is going to be "make sure that
SYS_HEAPINFO doesn't consider memory regions that are rom-devices"
(we already ignore read-only memory, but flash devices are
technically not read-only).

You don't mention which QEMU version you are using. We
rewrote the whole SYS_HEAPINFO handling in commit 5fc983af8b20d6927
(Feb 2022, should be in 7.0.0) because the old implementation
could produce some completely wrong results. Looking at the code
I guess this was with the new implementation, though.

Do you have a test binary I can reproduce this with? That would save
me a little time.

thanks
-- PMM