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

[Suzuki K Poulose]

On 25/09/2026 13:17, Catalin Marinas wrote:
> On Thu, Sep 24, 2026 at 02:51:59PM +0100, Suzuki K Poulose wrote:
> > From: Steven Price <steven.price@xxxxxxx>
> >
> > Activate the RMM after the basic configuration. This is a memory
> > transferring stateful operation.
> >
> > Reviewed-by: Gavin Shan <gshan@xxxxxxxxxx>
> > Reviewed-by: Jonathan Cameron <jonathan.cameron@xxxxxxxxxxxxxxxx>
> > Signed-off-by: Steven Price <steven.price@xxxxxxx>
> > Signed-off-by: Suzuki K Poulose <suzuki.poulose@xxxxxxx>
> > ---
> > Changes since v17:
> >   * Inline RMM_ACTIVATE command and remove the definitions from arm-rmi-cmds.h
> >   * Use scope-based cleanup to free sro object
> > Changes since v16:
> >   * Split into a new patch
> > ---
> >   drivers/firmware/arm_rmm/rmi.c | 13 ++++++++++++-
> >   1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/arm_rmm/rmi.c b/drivers/firmware/arm_rmm/rmi.c
> > index 035f21d3f26b6..0859f256e192b 100644
> > --- a/drivers/firmware/arm_rmm/rmi.c
> > +++ b/drivers/firmware/arm_rmm/rmi.c
> > @@ -834,7 +834,18 @@ static int __init arm64_init_rmi(void)
> >   	if (ret)
> >   		return ret;
> >   
> > -	return 0;
> > +	/* Activate the RMM */
> > +	struct rmi_sro_state *sro __free(kfree) = kmalloc_obj(*sro);
> > +	if (!sro)
> > +		return -ENOMEM;
> > +
> > +	ret = rmi_sro_memxfer_cmd(sro, GFP_KERNEL, SMC_RMI_RMM_ACTIVATE);
> > +	if (ret) {
> > +		pr_err("RMM activate failed (%d)\n", ret);
> > +		ret = ret < 0 ? ret : -ENXIO;
> > +	}
> > +
> > +	return ret;
>
> It was raised earlier this year [1] but I'm not sure it concluded. How
> do we handle kexec and kdump? I think RMI_RMM_DEACTIVATE only succeeds
> if nothing is delegated, so it would need all realms torn down first. If
> that's not feasible, we could at least block (non-crash) kexec like pKVM
> does.

You are right, we can't DEACTIVATE until all granules have been
"undelegated" back. Not just the Realms, but also the GPTs/Tracking
Metadata etc would need to be reclaimed (when we get to support
dynamic GPT/Tracking metadata). For now, we should block the kexec.
> Kdump gets even more interesting if it starts accessing delegated pages
> and getting GPF.
>
> [1] https://lore.kernel.org/r/CABpDEukEO4Y_fg8fv5Nr1_Pw_qOK=2UmioXk=WyPEzoEprPcGA@xxxxxxxxxxxxxx

Kdump may be a bit more easier, as the kdump kernel is supposed to use
the "reserved" region and vmcore access could handle the GPF and
provide "0"s to the reader ? May be this is one case where the
host needs to be able to handle GPFs.

Cheers
Suzuki

>