* Re: v6.13-rc1: Internal error: Oops - Undefined instruction: 0000000002000000 [#1] SMP
[not found] ` <20241206205602.7phcrxqsv4c6oul4@altlinux.org>
@ 2024-12-10 2:51 ` Vitaly Chikunov
2024-12-10 9:55 ` Marc Zyngier
0 siblings, 1 reply; 2+ messages in thread
From: Vitaly Chikunov @ 2024-12-10 2:51 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, Marc Zyngier, Oliver Upton
Cc: Shameerali Kolothum Thodi, Will Deacon, james.morse@arm.com,
Catalin Marinas, linux-kernel@vger.kernel.org, Mark Rutland,
Wangzhou (B), Gleb Fotengauer-Malinovskiy
On Fri, Dec 06, 2024 at 11:56:02PM +0300, Vitaly Chikunov wrote:
> 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@altlinux.org> wrote:
> > > On Tue, Dec 03, 2024 at 10:03:11AM +0000, Shameerali Kolothum Thodi wrote:
> >
> > 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?
>
> We tested the host with this patch applied over 6.6.63 and 6.13-rc1
> guest does not Oops anymore.
>
> I'd suggest this is also get backported to 6.12.y branch.
Please, can someone backport this patch to v6.12 and send to stable? This
would be really useful to have this fixed and it's noted this is a
critical bug.
Thanks,
>
> 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),
> >
^ permalink raw reply [flat|nested] 2+ messages in thread