Re: [PATCH v19 5/7] firmware: arm_rmm: Activate the RMM

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

On 29/09/2026 12:15, Catalin Marinas wrote:
> On Mon, Sep 28, 2026 at 07:28:20PM +0100, Suzuki K Poulose wrote:
>> On 28/09/2026 19:01, Catalin Marinas wrote:
>>> possible, to defer the RMM activation until the first user (still do the
>>> RMI probing as an initcall). If we run on RME-capable hardware and
>>> firmware but don't care about realms or TSM, we still get the normal OS
>>> functionality.
>>
>> Would you prefer this in the first drop of the RMM ? Or is this
>> something we could add as a separate series ?
> 
> I think we could add the deferring as a separate patch, maybe together
> with the KVM bits. An advantage of keeping it here if we merge this
> first is that we still exercise the activation path without full realm
> support or TSM. Otherwise a lot of this would be dead code until the
> other series arrive. Either way, do it as as separate patch on top of
> this series.
> 

I have been looking at the "on-demand" activation support and came
across the following design decision.

* We have KVM_CAP_ARM_RME which advertises that KVM can create Realm VMs
   to the userspace. A VMM could check this before it creates a Realm VM
   using KVM_CREATE_VM with type=RealmVM.


Now, we could delay the RMM activation as late as the KVM_CREATE_VM and
kick it off while we initialise the kvm as part of kvm_arch_init_vm().
But if that fails, we would fail the KVM_CREATE_VM.

The question is, what should KVM_CAP_ARM_RME indicate ?
We could initially enable the cap based on the presence of RMM (but not 
activated). However, should we turn the KVM_CAP_ARM_RME=off when we fail
to activate the RMM ? Is that senisble ? (i.e., runtime disabling a cap).

Cheers
Suzuki