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

[Catalin Marinas <catalin.marinas@arm.com>]

On Fri, Sep 25, 2026 at 04:02:24PM +0100, Suzuki K Poulose wrote:
> 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@arm.com>
> > > 
> > > Activate the RMM after the basic configuration. This is a memory
> > > transferring stateful operation.
> > > 
> > > Reviewed-by: Gavin Shan <gshan@redhat.com>
> > > Reviewed-by: Jonathan Cameron <jonathan.cameron@oss.qualcomm.com>
> > > Signed-off-by: Steven Price <steven.price@arm.com>
> > > Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> > > ---
> > > 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.

Looking more into this (and the memory hotplug story), I find it strange
that simply having RME and a valid RMM imposes all these restrictions
even if we never run or intend to run a realm. How common will
RME-capable systems with RMM firmware be that are not used for CoCo? Or
do we expect only CoCo systems to have capable/configured firmware (RME
may be present in silicon anyway)?

Ideally we'd defer the RMM configuration and activation (and the
tracking/GPT checks) until we first attempt to start a realm, keeping
only the RMI_VERSION/FEATURES probing at boot. Not sure how feasible
this is (memory is more fragmented by then for any contiguous donation).
If we manage it, kexec and memory hotplug just work on hosts that never
start a realm.

The next best thing for kexec is to tear down the realms, undelegate
the granules and deactivate the RMM before invoking kexec (with kdump
that's harder as we likely no longer have a controlled shutdown).

Similarly with memory hotplug, allow it if we haven't started any realms
and refuse realm creation afterwards if untracked memory was onlined.
Also, if the memory is onlined to ZONE_MOVABLE, neither guest_memfd nor
the kernel allocations we delegate come from there, so we could allow
it even with realms running.

> > 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@mail.gmail.com
> 
> 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.

Yes, I think so. I now realised that metadata delegation to the RMM
doesn't come from guest_memfd, so that's another case not helped by the
old series to unmap guest_memfd from the linear map. I'll reply to the
GPF thread.

-- 
Catalin