From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DC5BB381AE3; Fri, 25 Sep 2026 15:02:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790348560; cv=none; b=nwzGmL6Tqlniz+qtrUo6z3S0/yUnRsQz4dYug3RLJuPC2rip0KmVxnoJPc0Zo1p5+6q4a7zSbWXVI+434EBFYaQW0gA04THfFEPKRh/SWzGxbfpJagOvr1LIkVkfjh+3NvNSDHiGA8HVpXSoB9cok183to786fCDPPMj4mXnXXY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790348560; c=relaxed/simple; bh=85LE8mJXVs6JArsgWcvXfC7Xtvt9iQDJisLQSCB8z5M=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=TSktFfwCIhg+YMRM/wBxhhcTqbFWGsPx9xGOQ0rW7RlBdQXJMXfFAvm9llOseS/GBljaqPS6IpVVeDm7c+Hp9PXRYmIOiNki5slxjXensfFKAKb6besEtEnpcnp26THd6z3gsDoUTpYyos0cUK5pY3cYf4T3D3Y9zsQ2r+MI7Dk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=H5MONHZC; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="H5MONHZC" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C359C1688; Fri, 25 Sep 2026 08:02:25 -0700 (PDT) Received: from [10.57.10.17] (unknown [10.57.10.17]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 223813F85F; Fri, 25 Sep 2026 08:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1790348549; bh=85LE8mJXVs6JArsgWcvXfC7Xtvt9iQDJisLQSCB8z5M=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=H5MONHZCwvGc1eZswUFSIojrHQj6YlW7HZ5fNwn+jQVdGMqH/vBhYivsTR+JAtuyG Z/4jawUWYLuSRUIzDSPuriwInkylUHXsMJhTc4Rj+oQV87AUNcaPhHFRAvPX5/iJGO ZBeCQ+HGppvRK0/Wh/iPt2aKQErK4VUKtP3RuAS4= Message-ID: Date: Fri, 25 Sep 2026 16:02:24 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v19 5/7] firmware: arm_rmm: Activate the RMM Content-Language: en-GB To: Catalin Marinas 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 References: <20260924135201.850038-1-suzuki.poulose@arm.com> <20260924135201.850038-6-suzuki.poulose@arm.com> From: Suzuki K Poulose In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 >> >> Activate the RMM after the basic configuration. This is a memory >> transferring stateful operation. >> >> Reviewed-by: Gavin Shan >> Reviewed-by: Jonathan Cameron >> Signed-off-by: Steven Price >> Signed-off-by: Suzuki K Poulose >> --- >> 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 >