Hi Everyone,

The baseline implementation aligning TF-RMM to the RMM v2.0 Beta0 specification has now been merged [1]. Corresponding updates to TF-A-Tests [2] and TF-A [3] for RMM v2.0 have also been merged.

In TF-A, the default behaviour (whether to follow RMM v1.x or v2.0) is controlled via the build flag RMM_V1_COMPAT. This flag defaults to 0, meaning TF-A expects RMM v2.0 behaviour. The TF-A changes are currently in the integration branch and are expected to appear in master within the next couple of days.

The major features included in this update are:

  2. Base support for the new SRO flow for auxiliary granules in RMI_REC_CREATE and RMI_REC_DESTROY

As noted in the previous email, this represents base-level support. Further hardening and additional v2.0 features will follow.

For users who need the previous RMM v1.x implementation:

The kernel team has also published a base v2.0 branch : https://lore.kernel.org/all/20260318155413.793430-1-steven.price@arm.com/ (Public branches for Linux and kvmtool are referenced in the cover letter.)

A new Shrinkwrap overlay for 3-world configuration (cca.yaml) is now available, which pulls in the above kernel and kvmtool branches aligned to the v2.0 specification. To run a 3-world smoke test, refer to: https://tf-rmm.readthedocs.io/en/latest/getting_started/building-with-shrinkwrap.html#world-testing

Note: The DA software stack is still based on RMM v1.x. You will need to use the v1.x implementation referenced above.

Best Regards
Soby Mathew

[1] https://github.com/TF-RMM/tf-rmm/commit/1e2ab326cd54fea2de24c81ea8c802781345dad1
[2] https://git.trustedfirmware.org/plugins/gitiles/TF-A/tf-a-tests/+/847a9fa5ac381a4decdb6969f728413483d8fafa
[3] https://git.trustedfirmware.org/plugins/gitiles/TF-A/trusted-firmware-a/+/7ad4b5ed31e33dca21dd4d2f4a9f64f9b7d4db85


From: Soby Mathew via TF-A <tf-a@lists.trustedfirmware.org>
Date: Friday, 13 March 2026 at 09:40
To: tf-rmm@lists.trustedfirmware.org <tf-rmm@lists.trustedfirmware.org>, tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>
Cc: nd <nd@arm.com>
Subject: [TF-A] Re: RMMv2.0 implementation plan for TF-RMM

[+ 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/+/refs/heads/master/docs/getting_started/build-options.rst#1577

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