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

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

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

Cheers
Suzuki

>