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

[Suzuki K Poulose <suzuki.poulose@arm.com>]

On 25/09/2026 07:29, Gavin Shan wrote:
> On 9/24/26 11:51 PM, Suzuki K Poulose wrote:
>> 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


>> [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 <gshan@redhat.com>

Thanks Gavin ! Much appreciated

Cheers
Suzuki