[PATCH 1/2] KVM: arm64: Initialize HCR_EL2.E2H early
Marc Zyngier
maz at kernel.org
Fri Feb 28 01:43:20 PST 2025
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.
>
> > + *
> > + * Fruity CPUs seem to have HCR_EL2.E2H set to RAO/WI, but
> > + * don't advertise it (they predate this relaxation).
> > + *
> > + * Initalize HCR_EL2.E2H so that later code can rely upon HCR_EL2.E2H
> > + * indicating whether the CPU is running in E2H mode.
> > + */
>
> I think it is even better to clear the HCR_E2H bit first. This can
> avoid any dependency on the passed parameter 'val'.
What are you trying to avoid? A random value passed as a parameter to
the macro?
M.
--
Without deviation from the norm, progress is not possible.
More information about the linux-arm-kernel
mailing list