[PATCH 1/2] KVM: arm64: Initialize HCR_EL2.E2H early
Marc Zyngier
maz at kernel.org
Fri Feb 28 02:20:38 PST 2025
On Fri, 28 Feb 2025 09:52:50 +0000,
Mark Rutland <mark.rutland at arm.com> wrote:
>
> On Fri, Feb 28, 2025 at 09:43:20AM +0000, Marc Zyngier wrote:
> > On Fri, 28 Feb 2025 09:29:55 +0000,
> > Leo Yan <leo.yan at arm.com> wrote:
> > >
> > > Hi Mark,
> > >
> > > On Thu, Feb 27, 2025 at 06:05:25PM +0000, Mark Rutland wrote:
> > >
> > > [...]
> > >
> > > > +.macro init_el2_hcr val
> > > > + mov_q x0, \val
> > > > +
> > > > + /*
> > > > + * Compliant CPUs advertise their VHE-onlyness with
> > > > + * ID_AA64MMFR4_EL1.E2H0 < 0. On such CPUs HCR_EL2.E2H is RES1, but it
> > > > + * can reset into an UNKNOWN state and might not read as 1 until it has
> > > > + * been initialized explicitly.
> > >
> > > For ID_AA64MMFR4_EL1.E2H0 < 0 case, the code actually clears the
> > > HCR_EL2.E2H bit.
> > >
> > > Hence, the comment should be corrected as: "... it can reset into an
> > > UNKNOWN state and might not read as 0 until it has been initialized
> > > explicitly".
> >
> > The comment is just fine. It is the code that is wrong, as it avoids
> > setting E2H when E2H0 < 0 while we want the exact opposite behaviour.
> >
> > As a result, 'b.lt' really should be a 'b.ge'. Or the original code
> > kept as is.
>
> Ugh, yes. I got confused and got the condition backwards.
>
> Either works. Using 'b.ge' is closer to my intention -- I found the
> 'tbz' of the sign bit somewhat surprising and that needed a longer line
> after the lable name changed.
>
> Would you like me to respin, or would you be hapy to fix up when
> applying?
I can fix it on the fly, but it needs retesting, as I don't understand
how things could work in this state.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
More information about the linux-arm-kernel
mailing list