On Thu, 5 Dec 2024 at 10:14, Marcin Juszkiewicz <marcin.juszkiew...@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.juszkiew...@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