All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suzuki K Poulose <suzuki.poulose@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: kvm@vger.kernel.org, kvmarm@lists.linux.dev, maz@kernel.org,
	will@kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, steven.price@arm.com,
	aneesh.kumar@kernel.org, oupton@kernel.org, gshan@redhat.com,
	joey.gouly@arm.com, tabba@google.com, yuzenghui@huawei.com,
	linux-coco@lists.linux.dev, gankulkarni@os.amperecomputing.com,
	sdonthineni@nvidia.com, alpergun@google.com,
	fj0570is@fujitsu.com, WeiLin.Chang@arm.com,
	lpieralisi@kernel.org, enju.kohei@fujitsu.com,
	sudeep.holla@arm.com, jonathan.cameron@oss.qualcomm.com
Subject: Re: [PATCH v19 5/7] firmware: arm_rmm: Activate the RMM
Date: Mon, 28 Sep 2026 14:55:11 +0100	[thread overview]
Message-ID: <195cdfe4-a55a-453f-9c34-620738eca244@arm.com> (raw)
In-Reply-To: <70d47475-e26e-40e1-b409-b0c16aecb8c0@arm.com>

On 28/09/2026 10:08, Suzuki K Poulose wrote:
> 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.


I have the following patch (tested , but tf-RMM doesn't support 
DEACTIVATE yet), which correctly deactivates the RMM (well
at least tries).

---8>---


firmware: rmm: Deactivate RMM at reboot

Deactivate the RMM at system shutdown. This would allow a normal kexec 
to cleanup the state and boot into a new kernel gracefully.

Kdump kernels need not worry about an active RMM, as long as it can
handle the GPF on access to the Delegated granules.

Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
---
  arch/arm64/kernel/machine_kexec.c |  2 +
  drivers/firmware/arm_rmm/rmi.c    | 63 ++++++++++++++++++++++++++++++-
  include/linux/arm-rmi-cmds.h      | 10 +++++
  3 files changed, 73 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/kernel/machine_kexec.c 
b/arch/arm64/kernel/machine_kexec.c
index 8f9bc2327dc85..8f16f92a5d389 100644
--- a/arch/arm64/kernel/machine_kexec.c
+++ b/arch/arm64/kernel/machine_kexec.c
@@ -6,6 +6,7 @@
   * Copyright (C) Huawei Futurewei Technologies.
   */

+#include <linux/arm-rmi-cmds.h>
  #include <linux/interrupt.h>
  #include <linux/irq.h>
  #include <linux/kernel.h>
@@ -171,6 +172,7 @@ void machine_kexec(struct kimage *kimage)
  	BUG_ON(!in_kexec_crash && (stuck_cpus || (num_online_cpus() > 1)));
  	WARN(in_kexec_crash && (stuck_cpus || smp_crash_stop_failed()),
  		"Some CPUs may be stale, kdump will be unreliable.\n");
+	WARN(!in_kexec_crash && is_rmm_active(), "RMM is active, kexec will be 
unreliable.\n");

  	pr_info("Bye!\n");

diff --git a/drivers/firmware/arm_rmm/rmi.c b/drivers/firmware/arm_rmm/rmi.c
index 51343e9d5c2a9..5b695f3155b1c 100644
--- a/drivers/firmware/arm_rmm/rmi.c
+++ b/drivers/firmware/arm_rmm/rmi.c
@@ -7,6 +7,7 @@
  #include <linux/memblock.h>
  #include <linux/memory.h>
  #include <linux/arm-rmi-cmds.h>
+#include <linux/reboot.h>
  #include <linux/slab.h>

  #include <asm/memory.h>
@@ -15,6 +16,13 @@
  /* RMM v2.0 defines RmiFeatureRegister0 to RmiFeatureRegister4. */
  static unsigned long rmi_feat_reg_cache[5] __ro_after_init;
  static bool arm64_rmi_is_available;
+static bool arm64_rmm_active;
+
+bool is_rmm_active(void)
+{
+	return arm64_rmm_active;
+}
+EXPORT_SYMBOL_GPL(is_rmm_active);

  /**
   * rmi_granule_range_undelegate() - Undelegate a range of granules
@@ -1017,6 +1025,53 @@ bool is_rmi_available(void)
  }
  EXPORT_SYMBOL_GPL(is_rmi_available);

+static int rmi_rmm_deactivate(struct rmi_sro_state *sro)
+{
+	int ret;
+
+	if (!READ_ONCE(arm64_rmm_active))
+		return 0;
+
+	ret = WARN_ON(rmi_sro_memxfer_cmd(sro, GFP_KERNEL, 
SMC_RMI_RMM_DEACTIVATE));
+	if (ret)
+		return ret;
+
+	WRITE_ONCE(arm64_rmm_active, false);
+	WRITE_ONCE(arm64_rmi_is_available, false);
+
+	return ret;
+}
+
+static int rmi_reboot_notifier(struct notifier_block *nb,
+			       unsigned long action, void *data)
+{
+	int ret;
+
+	switch (action) {
+	case SYS_RESTART:
+	case SYS_HALT:
+	case SYS_POWER_OFF:
+		break;
+	default:
+		return NOTIFY_DONE;
+	}
+
+	struct rmi_sro_state *sro __free(kfree) = kmalloc_obj(*sro);
+
+	if (!sro)
+		return -ENOMEM;
+
+	ret = rmi_rmm_deactivate(sro);
+	if (ret)
+		pr_emerg("RMM Deactivation failed: %d\n", ret);
+
+	return NOTIFY_DONE;
+}
+
+static struct notifier_block rmi_reboot_nb = {
+	.notifier_call = rmi_reboot_notifier,
+};
+
  static int rmi_init_memory(void)
  {
  	int ret;
@@ -1025,7 +1080,10 @@ static int rmi_init_memory(void)
  	if (ret)
  		return ret;

-	return register_memory_notifier(&rmi_memory_nb);
+	ret = register_memory_notifier(&rmi_memory_nb);
+	if (ret)
+		return ret;
+	return register_reboot_notifier(&rmi_reboot_nb);
  }

  static int __init arm64_init_rmi(void)
@@ -1057,10 +1115,11 @@ static int __init arm64_init_rmi(void)
  		return ret;
  	}

+	WRITE_ONCE(arm64_rmm_active, true);
  	ret = rmi_init_memory();
  	if (ret) {
  		/* Deactivate the RMM */
-		WARN_ON(rmi_sro_memxfer_cmd(sro, GFP_KERNEL, SMC_RMI_RMM_DEACTIVATE));
+		(void)rmi_rmm_deactivate(sro);
  		return ret;
  	}

diff --git a/include/linux/arm-rmi-cmds.h b/include/linux/arm-rmi-cmds.h
index 8fd90914c161a..5d31a4104ce72 100644
--- a/include/linux/arm-rmi-cmds.h
+++ b/include/linux/arm-rmi-cmds.h
@@ -88,6 +88,16 @@ long rmi_sro_execute(struct arm_smccc_1_2_regs *regs);
  	__ret;								\
  })

+
+#ifdef CONFIG_ARM_RMM_RMI
+bool is_rmm_active(void);
+#else
+static inline bool is_rmm_active(void)
+{
+	return false;
+}
+#endif	/* CONFIG_ARM_RMM_RMI */
+
  /**
   * rmi_rtt_data_map_init() - Create a mapping at protected IPA, 
copying contents
   *			     from a given non-secure source granule.
-- 
2.43.0



  reply	other threads:[~2026-09-28 13:55 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-24 13:51 [PATCH v19 0/7] firmware: arm_rmm: Add RMM v2.0 base RMI support Suzuki K Poulose
2026-09-24 13:51 ` [PATCH v19 1/7] firmware: arm_rmm: Add SMC definitions for calling the RMM Suzuki K Poulose
2026-09-24 16:57   ` Jonathan Cameron
2026-09-24 22:15     ` Suzuki K Poulose
2026-09-24 17:05   ` Ackerley Tng
2026-09-24 22:49     ` Suzuki K Poulose
2026-09-24 13:51 ` [PATCH v19 2/7] firmware: arm_rmm: Check for RMI support at init Suzuki K Poulose
2026-09-24 14:00   ` sashiko-bot
2026-09-24 16:58   ` Jonathan Cameron
2026-09-25  0:00   ` Gavin Shan
2026-09-25  8:51     ` Suzuki K Poulose
2026-09-25  5:43   ` Gavin Shan
2026-09-25  8:50     ` Suzuki K Poulose
2026-09-25 10:42   ` Catalin Marinas
2026-09-25 15:23     ` Suzuki K Poulose
2026-09-27  9:29       ` Marc Zyngier
2026-09-28  8:05         ` Suzuki K Poulose
2026-09-24 13:51 ` [PATCH v19 3/7] firmware: arm_rmm: Configure the RMM with the host's page size Suzuki K Poulose
2026-09-24 17:03   ` Jonathan Cameron
     [not found]     ` <d4b768e5-c942-43cf-aea2-c266a8bab353@oss.qualcomm.com>
2026-09-25 14:56       ` Suzuki K Poulose
2026-09-26 13:38         ` Venkata Rao Kakani
2026-09-25  0:03   ` Gavin Shan
2026-09-24 13:51 ` [PATCH v19 4/7] firmware: arm_rmm: Add support for SRO Suzuki K Poulose
2026-09-24 14:08   ` sashiko-bot
2026-09-24 23:18     ` Suzuki K Poulose
2026-09-24 19:13   ` Jonathan Cameron
2026-09-24 23:10     ` Suzuki K Poulose
2026-09-25  5:24   ` Gavin Shan
2026-09-29 12:52     ` Suzuki K Poulose
2026-09-25 11:50   ` Catalin Marinas
2026-09-25 15:11     ` Suzuki K Poulose
2026-09-28  9:28   ` Catalin Marinas
2026-09-28 10:13     ` Suzuki K Poulose
2026-09-28 17:28       ` Catalin Marinas
2026-09-28 20:45         ` Suzuki K Poulose
2026-09-24 13:51 ` [PATCH v19 5/7] firmware: arm_rmm: Activate the RMM Suzuki K Poulose
2026-09-25 12:17   ` Catalin Marinas
2026-09-25 15:02     ` Suzuki K Poulose
2026-09-25 15:34       ` Alper Gun
2026-09-25 16:42       ` Catalin Marinas
2026-09-25 17:50         ` Suzuki K Poulose
2026-09-28  9:08           ` Suzuki K Poulose
2026-09-28 13:55             ` Suzuki K Poulose [this message]
2026-09-28 18:01               ` Catalin Marinas
2026-09-28 18:28                 ` Suzuki K Poulose
2026-09-29 11:15                   ` Catalin Marinas
2026-09-24 13:52 ` [PATCH v19 6/7] firmware: arm_rmm: Ensure the RMM has GPT entries for memory Suzuki K Poulose
2026-09-24 21:38   ` Jonathan Cameron
2026-09-24 23:30     ` Suzuki K Poulose
2026-09-25 15:30       ` Jonathan Cameron
2026-09-25  0:07   ` Gavin Shan
2026-09-29 11:01   ` Catalin Marinas
2026-09-29 12:15     ` Suzuki K Poulose
2026-09-29 22:17   ` Shanker Donthineni
2026-09-29 22:25     ` Suzuki K Poulose
2026-09-29 22:29   ` Shanker Donthineni
2026-09-30  8:17     ` Suzuki K Poulose
2026-09-24 13:52 ` [PATCH v19 7/7] firmware: arm_rmm: Add wrappers for Realm related RMI commands Suzuki K Poulose
2026-09-25 11:56   ` Catalin Marinas
2026-09-29 12:15     ` Suzuki K Poulose
2026-09-25  6:29 ` [PATCH v19 0/7] firmware: arm_rmm: Add RMM v2.0 base RMI support Gavin Shan
2026-09-25  9:03   ` Suzuki K Poulose
2026-09-29 10:50 ` Catalin Marinas
2026-09-29 12:14   ` Suzuki K Poulose

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=195cdfe4-a55a-453f-9c34-620738eca244@arm.com \
    --to=suzuki.poulose@arm.com \
    --cc=WeiLin.Chang@arm.com \
    --cc=alpergun@google.com \
    --cc=aneesh.kumar@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=enju.kohei@fujitsu.com \
    --cc=fj0570is@fujitsu.com \
    --cc=gankulkarni@os.amperecomputing.com \
    --cc=gshan@redhat.com \
    --cc=joey.gouly@arm.com \
    --cc=jonathan.cameron@oss.qualcomm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=sdonthineni@nvidia.com \
    --cc=steven.price@arm.com \
    --cc=sudeep.holla@arm.com \
    --cc=tabba@google.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.