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

[Suzuki K Poulose]

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