v6.13-rc1: Internal error: Oops - Undefined instruction: 0000000002000000 [#1] SMP
Vitaly Chikunov
vt at altlinux.org
Wed Dec 4 10:53:09 PST 2024
Marc,
On Wed, Dec 04, 2024 at 08:51:26AM +0000, Marc Zyngier wrote:
> On Tue, 03 Dec 2024 22:14:53 +0000,
> Vitaly Chikunov <vt at altlinux.org> wrote:
> >
> > I tried to verify that MPAM is advertised with qemu+gdb method, as
> > suggested by Oliver, but ID_AA64PFR0_EL1 register is not there.
> >
> > (gdb) i r ID_AA64PFR0_EL1
> > Invalid register `ID_AA64PFR0_EL1'
>
> Then there is a bug in either QEMU or the GDB stubs. This register
> exists, or you wouldn't be here.
>
> >
> > Are there other suggestions?
>
> Mark has described what the problem is likely to be. 6.6-stable needs
> to have 6685f5d572c22e10 backported, and it probably should have been
> Cc: to stable. Can you please apply the following patch to your *host*
> machine and retest?
Looks like I will be able to test this.
Thanks,
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 370a1a7bd369..258a39bcd3c7 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -1330,6 +1330,7 @@ static u64 __kvm_read_sanitised_id_reg(const struct kvm_vcpu *vcpu,
> val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MTE);
>
> val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_SME);
> + val &= ~ARM64_FEATURE_MASK(ID_AA64PFR1_EL1_MPAM_frac);
> break;
> case SYS_ID_AA64ISAR1_EL1:
> if (!vcpu_has_ptrauth(vcpu))
> @@ -1472,6 +1473,13 @@ static u64 read_sanitised_id_aa64pfr0_el1(struct kvm_vcpu *vcpu,
>
> val &= ~ID_AA64PFR0_EL1_AMU_MASK;
>
> + /*
> + * MPAM is disabled by default as KVM also needs a set of PARTID to
> + * program the MPAMVPMx_EL2 PARTID remapping registers with. But some
> + * older kernels let the guest see the ID bit.
> + */
> + val &= ~ID_AA64PFR0_EL1_MPAM_MASK;
> +
> return val;
> }
>
> @@ -1560,6 +1568,29 @@ static int set_id_dfr0_el1(struct kvm_vcpu *vcpu,
> return set_id_reg(vcpu, rd, val);
> }
>
> +static int set_id_aa64pfr0_el1(struct kvm_vcpu *vcpu,
> + const struct sys_reg_desc *rd, u64 user_val)
> +{
> + u64 hw_val = read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1);
> + u64 mpam_mask = ID_AA64PFR0_EL1_MPAM_MASK;
> +
> + /*
> + * Commit 011e5f5bf529f ("arm64/cpufeature: Add remaining feature bits
> + * in ID_AA64PFR0 register") exposed the MPAM field of AA64PFR0_EL1 to
> + * guests, but didn't add trap handling. KVM doesn't support MPAM and
> + * always returns an UNDEF for these registers. The guest must see 0
> + * for this field.
> + *
> + * But KVM must also accept values from user-space that were provided
> + * by KVM. On CPUs that support MPAM, permit user-space to write
> + * the sanitizied value to ID_AA64PFR0_EL1.MPAM, but ignore this field.
> + */
> + if ((hw_val & mpam_mask) == (user_val & mpam_mask))
> + user_val &= ~ID_AA64PFR0_EL1_MPAM_MASK;
> +
> + return set_id_reg(vcpu, rd, user_val);
> +}
> +
> /*
> * cpufeature ID register user accessors
> *
> @@ -2018,7 +2049,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
> { SYS_DESC(SYS_ID_AA64PFR0_EL1),
> .access = access_id_reg,
> .get_user = get_id_reg,
> - .set_user = set_id_reg,
> + .set_user = set_id_aa64pfr0_el1,
> .reset = read_sanitised_id_aa64pfr0_el1,
> .val = ID_AA64PFR0_EL1_CSV2_MASK | ID_AA64PFR0_EL1_CSV3_MASK, },
> ID_SANITISED(ID_AA64PFR1_EL1),
>
More information about the linux-arm-kernel
mailing list