[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z-ObUJQn2dGsgSsO@linux.dev>
Date: Tue, 25 Mar 2025 23:14:40 -0700
From: Oliver Upton <oliver.upton@...ux.dev>
To: "Emi Kisanuki (Fujitsu)" <fj0570is@...itsu.com>
Cc: 'Steven Price' <steven.price@....com>,
"'kvm@...r.kernel.org'" <kvm@...r.kernel.org>,
"'kvmarm@...ts.linux.dev'" <kvmarm@...ts.linux.dev>,
'Catalin Marinas' <catalin.marinas@....com>,
'Marc Zyngier' <maz@...nel.org>, 'Will Deacon' <will@...nel.org>,
'James Morse' <james.morse@....com>,
'Suzuki K Poulose' <suzuki.poulose@....com>,
'Zenghui Yu' <yuzenghui@...wei.com>,
"'linux-arm-kernel@...ts.infradead.org'" <linux-arm-kernel@...ts.infradead.org>,
"'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
'Joey Gouly' <joey.gouly@....com>,
'Alexandru Elisei' <alexandru.elisei@....com>,
'Christoffer Dall' <christoffer.dall@....com>,
'Fuad Tabba' <tabba@...gle.com>,
"'linux-coco@...ts.linux.dev'" <linux-coco@...ts.linux.dev>,
'Ganapatrao Kulkarni' <gankulkarni@...amperecomputing.com>,
'Gavin Shan' <gshan@...hat.com>,
'Shanker Donthineni' <sdonthineni@...dia.com>,
'Alper Gun' <alpergun@...gle.com>,
"'Aneesh Kumar K . V'" <aneesh.kumar@...nel.org>
Subject: Re: [PATCH v7 00/45] arm64: Support for Arm CCA in KVM
Hi Emi,
On Wed, Mar 26, 2025 at 02:14:35AM +0000, Emi Kisanuki (Fujitsu) wrote:
> Hi all,
>
> I tested Linux-cca cca-host/v7 patch with our Internal simulator based on QEMU (with CCA and MPAM support).
> A panic occurred when starting Realm, but I don't think this is a problem with the cca-host/v7 patch.
> The location of the panic is [1].
>
> [1]https://lore.kernel.org/linux-arm-kernel/20241030160317.2528209-4-joey.gouly@arm.com
> diff --git a/arch/arm64/kernel/cpuinfo.c b/arch/arm64/kernel/cpuinfo.c
> index 44718d0482b3..46ba30d42b9b 100644
> --- a/arch/arm64/kernel/cpuinfo.c
> +++ b/arch/arm64/kernel/cpuinfo.c
> @@ -478,6 +478,9 @@ static void __cpuinfo_store_cpu(struct cpuinfo_arm64 *info)
> if (id_aa64pfr0_32bit_el0(info->reg_id_aa64pfr0))
> __cpuinfo_store_cpu_32bit(&info->aarch32);
>
> + if (id_aa64pfr0_mpam(info->reg_id_aa64pfr0))
> + info->reg_mpamidr = read_cpuid(MPAMIDR_EL1); /////// panic occurred here.
> +
> cpuinfo_detect_icache_policy(info);
> }
>
> There was no problem with the cca-host/v5 patch (based on v6.12).
> This panic is caused by accessing MPAMIDR_EL1 when the chip supports MPAM.
> This functionality was enabled when the cca host patch base version was rebased from v6.12 to v6.13.
>
> I am not familiar with TF-A, but I think this maybe a TF-A's bug.
> Because It seems TF-A sets MPAM3_EL3.TRAPLOWER to 0 during normal guest boot in manage_extensions_nonsecure_per_world function[2].
> However, TF-A does not set it to 0 during Realm guest boot in manage_extensions_secure_per_world function.
> Therefore, a trap occurs against EL3 (TF-A), and it is likely being processed as an invalid instruction (Undef).
Your instinct is correct that this is *not* a kernel bug. It is the
responsibility of the RMM to provide a consistent feature set to the
Realm.
Looks like this was addressed recently in TF-RMM by hiding FEAT_MPAM:
https://github.com/TF-RMM/tf-rmm/commit/7b0874403726d215c40054abfd5d8704049f8dac
Thanks,
Oliver
Powered by blists - more mailing lists