[+ TF-A list for FYI] Hi All, An update on v2.0 migration.
As RMM and the rest of the software stack are being prepared for the initial v2.0 migration, TF-A has introduced a new build configuration flag, RMM_V1_COMPAT, to control the world-switch behaviour between RMM v1.x and RMM v2.0 [1] .
This flag is enabled by default, meaning the default behaviour currently corresponds to RMM v1.x. Once TF-RMM is ready to merge the v2.0 support, the default value of this flag will be changed to 0. The flag also updates the EL3–RMM interface major version, allowing incompatibility with TF-A related to this build configuration to be detected at runtime.
We expect the initial v2.0 changes in TF-RMM to be merged by the end of this month. As mentioned in the previous email, we will create a v1.x branch prior to this and provide an update here.
[1] https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/re...
Best regards, Soby Mathew
From: Soby Mathew via tf-rmm tf-rmm@lists.trustedfirmware.org Date: Thursday, 5 February 2026 at 09:42 To: tf-rmm@lists.trustedfirmware.org tf-rmm@lists.trustedfirmware.org Cc: nd nd@arm.com Subject: [tf-rmm] RMMv2.0 implementation plan for TF-RMM
Hi Everyone,
The RMM v2.0 Beta 0 specification has been published here: https://developer.arm.com/documentation/den0137/latest/ As you may have noticed, this release introduces breaking changes to the RMI APIs (host side), while the RSIs (guest side) remain backward compatible. Nearly all ABIs are affected, and the scope of these changes makes it highly disruptive to maintain support for both RMI v1.x and RMI v2.0 within the same codebase. We do not expect RMI v1.x to be deployed in production, and retaining support for it would increase development overhead and the risk of introducing bugs. A more pragmatic approach is to branch the current RMM codebase at the RMI v1.x ABI and then migrate the mainline to the RMI v2.0 ABI. This will be a breaking change for host-side components that rely on the older RMI ABI. Given the extent of the ABI changes, significant effort will be required to align with RMI v2.0, and this approach allows the team to focus on upstreaming the new ABI support efficiently. The initial RMI v2.0 upstreaming will consist of a series of commits that together form an initial RMM implementation targeting the RMM v2.0 specification. This initial implementation will not be fully feature-complete with respect to the v2.0 spec, and we expect to continue layering additional RMM v2.0 ABI-related changes on top as the implementation matures during the course of the year. That said, we intend to maintain integration with an externally available, compatible Linux host kernel branch throughout this process. The initial RMI v2.0 RMM implementation will be compatible with an initial v2.0-based host kernel, and we will notify the mailing list once this integration is available to pick up (likely end of March ’26). If and when we need to introduce further ABI changes that break compatibility with a previously published kernel branch, we will call this out explicitly in advance and indicate when an updated kernel branch will be available for integration.
We plan to keep RMI v1.x ABI as a separate branch and selectively merge bug fixes on a request or need basis. Please let us know if you have any concerns regarding this plan within the next two weeks.
Best Regards Soby Mathew