Re: [PATCH v16 22/45] KVM: arm64: CCA: Handle RMI_EXIT_RIPAS_CHANGE

[Marc Zyngier]

On Mon, 07 Sep 2026 12:58:22 +0100,
Suzuki K Poulose <suzuki.poulose@xxxxxxx> wrote:
> 
> On 07/09/2026 11:10, Marc Zyngier wrote:
> > On Mon, 07 Sep 2026 06:05:29 +0100,
> > Kohei Enju <enju.kohei@xxxxxxxxxxx> wrote:
> > 
> > [...]
> > 
> >> Although the root cause is an RMM bug, should we also guard RIPAS_SET
> >> against this no-progress case?
> > 
> > No. We really should *prevent* the kernel from using a known broken
> > RMM. Which brings me to one of my long standing request: how to we
> > enforce the minimum version of RMM that KVM is willing to work with?
> 
> (1) Do you mean the RMM ABI version ?
> (2) Or the particular build version of a given RMM firmware
> implementation ?
> 
> As far as (1) is considered, the kernel already sticks to a single
> version, v2.0 and doesn't support anything else. And we are fine with
> KVM/Linux supporting a single version of RMM and deprecating the
> support for older RMM versions as we decide to move on.
> 
> As for (2), the RMM ABI doesn't provide any information about the
> build/fix version for a given implementation. I will raise this
> within Arm.

But it appears that only checking for RMM v2.0 wouldn't be sufficient
in the case that Kohei faces. Nothing distinguishes a vanilla RMM from
a fixed one, as we can only check for the ABI.

We need a way to identify *implementations* so that we can refuse to
use one that is known to be broken. And given that each and every
vendor already have their own toy RMM, each with their own "added
value", it cannot be a simple "build number" identifier.

This is not the first time I ask for this.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.