Merge changes from topic "rmm-lfa" into integration

* changes:
feat(rmmd): add RMM_RESERVE_MEMORY SMC handler
feat(rmmd): add per-CPU activation token

feat(rmmd): add RMM_RESERVE_MEMORY SMC handler

At the moment any memory required by an R-EL2 manager (RMM) needs to
be known at compile time: that sets the size of the .data and .bss
segments. Some

feat(rmmd): add RMM_RESERVE_MEMORY SMC handler

At the moment any memory required by an R-EL2 manager (RMM) needs to
be known at compile time: that sets the size of the .data and .bss
segments. Some resources depend on the particular machine this will be
running on, the prime example is TF-RMM's granule array, which needs to
know the maximum memory supported beforehand. Other data structures
might depend on the number of CPU cores.

To provide more flexibility, but keep the memory footprint as small as
possible, let's introduce some memory reservation SMC. Any RMM
implementation can ask EL3 for some memory, and would get the physical
address of a usable chunk of memory back. This must happen at RMM boot
time, so before the RMM concluded the boot phase with the
RMM_BOOT_COMPLETE SMC call. Also there is no provision to free memory
again, this would not be needed for the use case of sizing platform
resources, and avoids the complexity of a full-fledged memory allocator.

Add the new RMM_RESERVE_MEMORY command to the implementation defined
RMM-EL3 SMC interface, both in code and documentation. The actual memory
reservation is made a platform implementation, but a simple
implementation is provided, which is used for the FVP platform already:
it will just pick the next matching chunk of memory from the top end of
the RMM carveout. This way the memory reservation will grow down from
the end of the carveout, in a stack-like fashion, until it reaches the
end of the RMM payload, located at the beginning of the carveout. Since
secondary cores might also reserve memory at boot time, there is a
spinlock to protect the simple allocation algorithm.
Other platforms can choose to provide a more sophisticated reservation
algorithm, for instance one taking NUMA locality into account.

This patch just provides the call, at this point there is no obligation
to use the feature, although future TF-RMM versions would rely on it.

Change-Id: I096ac8870ee38f44e18850779fcae829a43a8fd1
Signed-off-by: Andre Przywara <andre.przywara@arm.com>

show more ...