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
Hello,
We are observing a recurring virtual‑timer IRQ loop during Realm guest bring‑up under TF‑RMM with RME enabled. The problem seems to be an ordering issue around restoring Realm timer state at EL2 and subsequently evaluating pending timer conditions.
When a virtual-timer interrupt is taken to EL2-R, the timer registers (CNTV_CTL=0x5 and CNTV_CVAL) are saved, and the IRQ is then reported to host OS.
When EL2 restores CNTV_CTL and CNTV_CVAL on return from the host, the write sequence is not synchronized before EL2 performs the timer‑pending check in the function check_pending_timers(). Because CNTVCT continues to advance, and CNTV_CVAL < CNTVCT is already true at restore time, the read of CNTV_CTL can reflect a stale value (0x1). As a result, EL2 does not set CNTHCTL_EL2.CNTVMASK, fails to clear the pending virtual‑timer interrupt, and the IRQ is re‑asserted immediately upon Realm re‑entry—causing the repeated exit/entry loop.
Inserting an isb() after restoring the Realm’s timer registers and before performing the timer‑pending check helped resolve the issue.
I’d appreciate any feedback.
Thanks
