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@xxxxxxx > 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
