Re: [PATCH for-5.2] target/arm: Make SYS_HEAPINFO work with RAM that doesn't start at 0

[Peter Maydell]

On Thu, 19 Nov 2020 at 11:26, Alex Bennée <alex.bennee@linaro.org> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
> > QEMU's implementation when in system emulation mode is very
> > simplistic: we say that the heap starts halfway into RAM and
> > continues to the end of RAM, and the stack starts at the top of RAM
> > and works down to the bottom.
>
> So there is nothing to stop this value being in the middle of say a
> loaded kernel or something that happens to overrun into the second half
> of memory? AFAICT if an initrd is ever used it will likely smash that.

Correct, but the only code that uses SYS_HEAPINFO will be
the libc runtime startup code in simple 'bare metal' test
applications, which are likely to be pretty small.

> > Unfortunately the code assumes that
> > the base address of RAM is at address 0, so on boards like 'virt'
> > where this is not true the addresses returned will all be wrong and
> > the guest application will usually crash.
> >
> > Conveniently since all Arm boards call arm_load_kernel() we have the
> > base address of the main RAM block in the arm_boot_info struct which
> > is accessible via the CPU object.  Use this to return sensible values
> > from SYS_HEAPINFO.
>
> It's certainly an improvement but it feels like it could be a bit
> smarter. Maybe it's not an issue for sort of things that use
> semihosting?

This is what the comment about "TODO: Make this use the limit
of the loaded application" is about -- in theory if we know
what the ELF file we've just loaded is we could put the
heap start there rather than just assuming "the loaded
application is probably not using half of RAM for its image".
But the benefit in trying to do that is not great and the
complexity is quite large, given how many ways we have of
loading guest code. (I guess the theoretical ideal would
involve asking the rom-blob code for the largest available
empty space?)

thanks
-- PMM