Re: [PATCH v19 0/7] firmware: arm_rmm: Add RMM v2.0 base RMI support

On 25/09/2026 07:29, Gavin Shan wrote:

On 9/24/26 11:51 PM, Suzuki K Poulose wrote:

quoted

This series adds the generic firmware layer for talking to the Realm
Management Monitor (RMM), as specified by the RMM v2.0-bet3
specification[1]. It is the first part of the Arm CCA host support that
was previously posted as part of the larger KVM series.

The split allows this RMM support to be used as a base for other work,
including Aneesh's PCI IDE support with Arm CCA RMM as the TSM,
  without depending on the KVM Realm support that will follow as separate
  series. (See more on that below)

The series adds:

  * The RMI SMC definitions and direct-call wrappers.

  * RMM discovery and version checks during firmware init.

  * RMM host configuration, including the host page size.

  * Stateful RMI Operation (SRO) infrastructure for commands which the RMM
    can complete across multiple SMC calls while requesting or returning
    memory to the host.

  * Verification that granule tracking is available at fine granularity.
    Fine-grained tracking allows each granule in the system to be tracked
    independently, which is required before individual granules can be
    delegated. A future series will add support for dynamically supplying
    memory to the RMM for this tracking.

  * Support for fully firmware-managed systems, where the Granule Protection
    Tables for memory regions are allocated and managed by firmware. RMM v2.0
    also allows dynamic GPT creation on demand; support for that will be added
    in a later series.

  * Wrappers for the RMI commands that are used for managing the "Realm VM"
    lifecycle. This is added in to make it easier for the on-going KVM support
    to evolve in parallel pieces.

If the platform firmware cannot manage the granule tracking or the GPTs, we
bail out and deactivate the RMM, reclaiming any memory that we have donated.

The RMM v2.0 spec introduces Stateful RMI Operations (SROs), which allow
the RMM to complete an operation over several SMC calls while requesting
or returning memory to the host. This allows interrupts to be handled in
the middle of an operation and lets the RMM dynamically allocate memory
for internal tracking purposes. For example, RMI_REC_CREATE no longer
needs auxiliary granules to be provided up front, and can instead
request memory during the operation.

This series applies on v7.3-rc2 and a branch is available at [2]. The KVM
CCA support that builds on this series is available at [3] as an integration
branch. The KVM support depends on guest-memfd-in-place conversion support v13
from Ackerley [4], we plan to split that into parts, which apply cleanly on
v7.3-rcx without any dependency and is in progress. This will be made available
as soon as it is ready. Until then [3] shows how this base series enables KVM
CCA support. You may find the tf-RMM [5] and kvmtool support [6] below.

[1] RMM spec : https://support.arm.com/documentation/den0137/2-0bet3/
[2] This series: https://gitlab.arm.com/linux-arm/linux-cca.git cca/ cca-host/fw_rmm/v19
[3] KVM CCA v17 integration branch: https://gitlab.arm.com/linux-arm/ linux-cca.git cca/cca/cca-host/kvm-v20/integration

s/v17/v20 ?

Yikes, I have pushed this in the kvm-v20, with the changes to the RMI_RESULT instead of RMI_RETURN etc. So the branch is correct, but the description is not. I will rectify that

quoted

[4] Gmem inplace conversion https://github.com/googleprodkernel/linux- cc/tree/guest_memfd-inplace-conversion-v13
[5] TF-RMM https://git.trustedfirmware.org/TF-RMM/tf-rmm.git main (commit: 134266ae)
[6] kvmtool https://gitlab.arm.com/linux-arm/kvmtool-cca.git tag:cca- kvm-v20 (Also cca/kvm-v18)

Known issues: RMMv2.0 spec.
  * RmiOpMemDonateReq:count (Uint14) is incompatible with RmiAddrRangeDesc4KB
   (Uint10) and RmiAddrRangeDesc16KB (Uint12). i.e., a larger contiguous request
   may not be satisfiable by the host. This is resolved in the RMM spec, by clamping
   the upper limit on the number to match the RmiAddrRangeDesc* and will be published
   in the next release.
  * RMM to clarify the scenarios that triggers the RMI_BLOCKED and the
    recommendations to limit the cases.

Applied this series on top of upstream linux v7.3.rc4. The built kernel can boot up on
GH200 machine and CCA host emulated by QEMU with various combinations: 4KB or 64KB base
page size, CONFIG_ARM_RMM_RMI is {Y, N}. The RMI is only detected and configured on CCA
host when the base page size is 4KB because RMM only support 4KB granule size at present.
Details can be found from TF-RMM/runtime/rmi/ granule.c::smc_rmm_config_set(). Besides,
some of the added functions based on the RMI calls aren't covered by the tests obviously.
So I think this series doesn't introduce regressions at least.

Tested-by: Gavin Shan <redacted>

Thanks Gavin ! Much appreciated

Cheers
Suzuki