Re: [PATCH v19 5/7] firmware: arm_rmm: Activate the RMM
From: Suzuki K Poulose
Date: Fri Sep 25 2026 - 13:51:20 EST
Hi Catalin
On 25/09/2026 17:42, Catalin Marinas wrote:
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@xxxxxxx>
Activate the RMM after the basic configuration. This is a memory
transferring stateful operation.
...
+
+ 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)?
There is another angle to this :
RMM may act as a TSM (as in the Trusted Security Manager in PCI TDISP)
context and provide setting up IDE connection between the RootPort/
EndPoint. So, the trigger point for the RMM activation would become the "First Delegate" request.
Running an RMM just for the "TSM" functionality is not ideal.
In the absence of RMM, Linux can act as the baremetal TSM. But when the
RMM is present, we must use the RMM as the TSM, especially if the
Device will be assigned to a Realm.
FEAT_RME capable systems don't need to enable RMM unless they want to
run CoCo guests.
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).
This is quite complicated, when we get the dynamic metadata support,
especially with the self-describing L1GPT and Tracking metadata.
But not impossible.
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.
I will double check this.
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.
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.
Ok, lets discuss on that thread.
Cheers
Suzuki