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

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

On 25/09/2026 18:50, Suzuki K Poulose wrote:
> 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.

Looking at this again we could :

a. If the user triggers a graceful kexec reboot, i.e, without forced,
    we should be able to deactivate the RMM. Since all processes are
    killed, Realm VMs must be off and all granules reclaimed.
    When we get to dynamic GPT/Tracking, we should additionally
    reclaim them back.
b. For forced reboot kexec, I don't think there is a safe way.

We have two options here :

1. Disable kexec reboot (allowing kexec kdump) when the RMM is active
    at kexec_load. I prefer this for now, and we could goto 2 eventually.

2. Back out from machine_kexec() if the RMM was still active.
    This allows (a) above.

> 
>>
>> 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.

Yep, we could do this, and I have added the following hunk :

diff --git a/drivers/firmware/arm_rmm/rmi.c b/drivers/firmware/arm_rmm/rmi.c
index b7332b066044d..51343e9d5c2a9 100644
--- a/drivers/firmware/arm_rmm/rmi.c
+++ b/drivers/firmware/arm_rmm/rmi.c
@@ -997,6 +997,11 @@ static int rmi_memory_notifier(struct 
notifier_block *nb,

         start = PFN_PHYS(arg->start_pfn);
         end = PFN_PHYS(arg->start_pfn + arg->nr_pages);
+
+       /* Neither guest-memfd nor the kernel allocations can come from 
MOVABLE */
+       if (page_zonenum(phys_to_page(start)) == ZONE_MOVABLE)
+               return NOTIFY_DONE;
+
         ret = rmi_prepare_memory(start, end);

         return notifier_from_errno(ret);

Suzuki