Re: [PATCH 1/1] hw/arm/sbsa-ref: bump default memory size to 2GB

[Peter Maydell]

On Thu, 5 Dec 2024 at 10:14, Marcin Juszkiewicz
<marcin.juszkiewicz@linaro.org> wrote:
>
> W dniu 4.12.2024 o 21:50, Philippe Mathieu-Daudé pisze:
> > On 4/12/24 13:17, Leif Lindholm wrote:
> >> On 2024-12-02 10:53, Marcin Juszkiewicz wrote:
> >>> W dniu 26.11.2024 o 14:14, Peter Maydell pisze:
> >>>> On Tue, 26 Nov 2024 at 08:49, Marcin Juszkiewicz
> >>>> <marcin.juszkiewicz@linaro.org> wrote:
> >>>>>
> >>>>> We are working on adding RME support to SBSA Reference Platform.
> >>>>> When RME is enabled then RMM (Realm Managment Monitor) takes 1072MB of
> >>>>> memory for own use. Which ends with firmware panic on 1GB machine.
> >>>>
> >>>> Reasonable change, but isn't it also a bug in the RMM that it
> >>>> grabs 1GB of RAM regardless of how much RAM the machine
> >>>> actually has?
> >>>
> >>> I think that the goal is "get it working" first and then optimize.
> >>
> >> I agree on a different platform this could feel quite hacky, but in
> >> reality even 2GB falls within "ridiculously low for an SBSA platform".
> >>
> >> If we're worried about overhead for CI jobs that do not require the
> >> feature, we could always conditionalize it on RME being enabled. But
> >> I'd be happy to wait and see.
> >
> > I'd rather do that, since it is as simple as:
>
> This is sbsa-ref not sbc-ref. Let it just have that 2GB of ram. None of
> existing SBSA systems comes with such low amount.

Yes, I think I agree here. Changing the default RAM size
based on whether the CPU does or does not have a particular
feature is unusual and not something we do on other board
types, and it definitely doesn't match the general intention
that sbsa-ref is a "looks like real hardware" machine.

The problem with using 2GB, though, is that it doesn't
work on 32-bit hosts, which have a max of 2047MB (and
if you try larger then hw/core/machine.c will error out with
"at most 2047 MB RAM can be simulated").

As a result we have several board types which have an ifdef
to say "limit the RAM size to 1GB if HOST_LONG_BITS is 32".

(I think this limit primarily derives from ramptr_t
being defined as a uintptr_t, but also trying to malloc
2GB on a 32-bit host is unlikely to work very well.)

thanks
-- PMM