Add support for RME extension to SBSA

[mathieupoirier]

Hi maintainers,

This pull request is adding support for the RME extension to the SBSA machine. When RME is enabled, the RMM is occupying the first 1GB of system RAM, followed by the DT. This reality needs to be reflected in the base RAM address and more space in flash need to be reserved. Otherwise it is the same configuration as the non-RME aware SBSA implementation.

Thanks,
Mathieu

[hrw]

I wonder can we move PcdSystemMemoryBase by those 1072MB always.

Then check "is there RME present" and if not then add that memory as another entry in memory map. That may require SMC call to TF-A to ask for RME (or other way as I am not familiar with RME yet).

This way one firmware image would work for the platform despite which firmware options are enabled/present.

[mathieupoirier]

@hrw ok, that's a valuable point. I am completely new to EDK2, can you provide pointers to here the SMC call should be made and the memory map entry added?

[hrw]

All SMC are in Silicon/Qemu/SbsaQemu/Library/SbsaQemuHardwareInfoLib/SbsaQemuHardwareInfoLib.c on EDK2 side and in plat/qemu/qemu_sbsa/sbsa_sip_svc.c on TF-A side.

When it comes to memory map - check functions which call GetMemInfo() in Silicon/Qemu/* - on NUMA systems we use SMC to get info about all memory nodes and add them into memory map.

So maybe instead of creating copy of dsc/fdf etc:

• move memorybase to get space for RME (so you can check does it work with/without RME using hardcoded "is RME present or not")
• add GetRmeInfo() function to SbsaHardwareInfoLib (it may return hardcoded value at start)
• add SMC call to TF-A so it will report state of RME
• use above SMC call in GetRmeInfo() function (handle situation when TF-A respond with "sorry, unknown SMC" cause people will get such combos)
• if no RME then add memory reserved for RME into memory map

NOTE: TF-A 2.12 and edk202411 are coming. RME code for both of them will rather be merged after releases to make sure that we have combo which works for users.