3. RMM Fake host architecture¶
RMM supports building and running the program natively as a regular user-space
application on the host machine. It achieves this by emulating the
specific parts of the program on the host machine by suitable hooks in the
program. The implementation of the hooks can differ based on the target
employment of running the program in this mode. Some of the foreseen
employment scenarios of this architecture includes:
Facilitate development of architecture independent parts of RMM on the host machine.
Enable unit testing of components within RMM with the benefit of not having to mock all the dependencies of the component.
Leverage host development environment and tools for various purposes like debugging, measure code coverage, fuzz testing, stress testing, runtime analysis of program etc.
Enable RMM compliance testing and verification of state machine and locking rules on the host machine.
Profile RMM on the host machine and generate useful insights for possible optimizations.
We expect the fake host architecture to be developed over time in future to cover some of the employment scenarios described above. The current code may not reflect the full scope of this architecture as discussed in this document.
The fake host architecture has some limitations:
The architecture is not intended to support multi-thread execution. The intrisics to support critical section and atomics are emulated as NOP.
Cannot execute AArch64 assembly code on the host due to obvious reasons.
Cannot emulate AArch64 exceptions during RMM execution although some limited form of handling exceptions occurring in Realms can probably be emulated.
The program links against the native compiler libraries which enables use of development and debug features available on the host machine. This means the libc implementation in RMM cannot be verified using this architecture.
The fake host architecture config is selected by setting the config
RMM_ARCH=fake_host and the platform has to be set to a variant
of host when building RMM. The different variants of the host
platform allow to build RMM for each of the target employment
scenarios as listed above.
3.1. Fake host architecture design¶
The above figure shows the fake host architecture design. The architecture independent parts of RMM are linked against suitable host emulation blocks to enable the program to run on the host platform.
The EL3 (monitor) emulation layer emulates the entry and exception from EL3 into Realm-EL2. This includes entry and exit from RMM as part of RMI handling, entry into RMM as part of warm/cold boot, and EL3 service invocations by RMM using SMC calls. Similarly the Realm entry/exit emulation block allows emulation of running a Realm. It would also allow to emulate exit from Realm due to synchronous or asynchronous exceptions like SMC calls, IRQs, etc.
The hardware emulation block allows to emulate sysreg accesses,
granule memory delegation and NS memory accesses needed for RMM. Since
RMM is running as a user space application, it does not have the ability
to map granule memory to a Virtual Address space. This capability is
needed for the
slot buffer component in RMM. Hence there is
also need to emulate VA mapping for this case.
The AArch64 intrinsics emulation block allows emulation of exclusives, assembly instructions for various architecture extensions, barriers and atomics, cache and TLB operations although most of them are defined as NOP at the moment.
Within the RMM source tree, all files within the
folder of each component implement the necessary emulation on host.
Depending on the target employment for the fake host
architecture, it is necessary to adapt the behaviour of
the emulation layer. This is facilitated by the APIs defined
host_harness.h header. The implementation of the API
is done by the
host platform and each variant of the
can have a different implementation of the API suiting its
target employment. The API also facilitates test and verification
of the emulated property as needed by the employment.
3.2. Fake host architecture employment scenarios implemented or ongoing¶
This section describes the currently implemented scenarios utilizing the fake host architecture.
Unit testing framework in RMM which allows testing public API of components and generation of code coverage data.