[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aJDLp+2Tuv7SMxK7@e129823.arm.com>
Date: Mon, 4 Aug 2025 16:03:03 +0100
From: Yeoreum Yun <yeoreum.yun@....com>
To: Marc Zyngier <maz@...nel.org>
Cc: catalin.marinas@....com, will@...nel.org, broonie@...nel.org,
oliver.upton@...ux.dev, anshuman.khandual@....com, robh@...nel.org,
james.morse@....com, mark.rutland@....com, joey.gouly@....com,
ry111@...111.site, Dave.Martin@....com, ahmed.genidi@....com,
kevin.brodsky@....com, scott@...amperecomputing.com, mbenes@...e.cz,
james.clark@...aro.org, frederic@...nel.org, rafael@...nel.org,
pavel@...nel.org, ryan.roberts@....com, suzuki.poulose@....com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, kvmarm@...ts.linux.dev
Subject: Re: [PATCH 10/11] KVM: arm64: nv: support SCTLR2_ELx on nv
Hi Marc,
> [...]
>
> > diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> > index dc1d26559bfa..a4d3b2d2fd80 100644
> > --- a/arch/arm64/kvm/nested.c
> > +++ b/arch/arm64/kvm/nested.c
> > @@ -1704,6 +1704,19 @@ int kvm_init_nv_sysregs(struct kvm_vcpu *vcpu)
> > TCR2_EL2_AMEC1 | TCR2_EL2_DisCH0 | TCR2_EL2_DisCH1);
> > set_sysreg_masks(kvm, TCR2_EL2, res0, res1);
> >
> > + /*
> > + * SCTLR2_EL2 - until explicit support for each feature, set all as RES0.
> > + */
> > + res0 = SCTLR2_EL2_RES0 | SCTLR2_EL2_EMEC;
> > + res0 |= SCTLR2_EL2_EASE;
> > + res0 |= SCTLR2_EL2_NMEA;
> > + res0 |= (SCTLR2_EL2_EnADERR | SCTLR2_EL2_EnANERR);
> > + res0 |= SCTLR2_EL2_EnIDCP128;
> > + res0 |= (SCTLR2_EL2_CPTA | SCTLR2_EL2_CPTA0 |
> > + SCTLR2_EL2_CPTM | SCTLR2_EL2_CPTM0);
> > + res1 = SCTLR2_EL2_RES1;
> > + set_sysreg_masks(kvm, SCTLR2_EL2, res0, res1);
>
> This patch is obsolete, but I'd like to point out that this is not the
> way we describe these things. Each bit of the register needs to be
> tracked against the feature it is part of, and not blindly added to
> the RES0 set. See
>
> https://lore.kernel.org/all/20250708172532.1699409-15-oliver.upton@linux.dev/
>
> for the equivalent change.
>
> You should *NEVER* describe a functional bit as RESx without
> considering whether the feature is exposed to the guest, irrespective
> of what the kernel supports.
Thanks to let me know.
I'll keep in mind :)
--
Sincerely,
Yeoreum Yun
Powered by blists - more mailing lists