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

[Suzuki K Poulose <suzuki.poulose@arm.com>]

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@arm.com>
>>>>
>>>> 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@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.

Ok, lets discuss on that thread.

Cheers
Suzuki