[PATCH 0/5] Backport ARM64 VHE boot fixes to 6.6.y

[Colton Lewis]

Oliver Upton <oupton at kernel.org> writes:

> Circling back around...

> On Wed, Jul 01, 2026 at 04:23:21PM -0700, Oliver Upton wrote:
>> The subject prefix should be "[PATCH 6.6 0/5]" so people know right up
>> front where this is going.

>> On Wed, Jul 01, 2026 at 08:43:37PM +0000, Colton Lewis wrote:
>> > This series backports VHE CPU boot fixes to the 6.6.y stable branch.
>> >
>> > These fixes are already present in the 6.12.y stable branch (and
>> > newer), but are missing in 6.6.y. They are required to enable booting
>> > L1 guests with nested virtualization enabled (kvm-arm.mode=nested).

>> It's a bit worse than this. The architecture retroactively made
>> FEAT_E2H0 an optional feature, there are now implementations in the wild
>> that do not support the feature.

>> > Without these patches, a 6.6.y guest boots with HCR_EL2.E2H
>> > incorrectly configured (because it misses VHE-only detection or early
>> > initialization), causing early boot hangs/trap loops.
>> >
>> > Conflict resolutions:
>> > - Patch 4 (KVM: arm64: Initialize HCR_EL2.E2H early) had conflicts in
>> >   arch/arm64/kvm/hyp/nvhe/hyp-init.S due to differences in state
>> >   initialization. Resolved by extracting EL2 state initialization into
>> >   __kvm_init_el2_state.
>> > - Patch 5 (arm64: Revamp HCR_EL2.E2H RES1 detection) had conflicts in
>> >   arch/arm64/include/asm/el2_setup.h. Resolved by using raw msr hcr_el2
>> >   instead of the missing msr_hcr_el2 macro.
>> >
>> >
>> > Marc Zyngier (4):
>> >   arm64: sysreg: Add layout for ID_AA64MMFR4_EL1
>> >   arm64: Treat HCR_EL2.E2H as RES1 when ID_AA64MMFR4_EL1.E2H0 is
>> >     negative
>> >   arm64: Fix early handling of FEAT_E2H0 not being implemented
>> >   arm64: Revamp HCR_EL2.E2H RES1 detection
>> >
>> > Mark Rutland (1):
>> >   KVM: arm64: Initialize HCR_EL2.E2H early

> Please go through and correct all of the SHA1s for the cherry-picks,
> smells like some LLM just hallucinated some bits given how close they
> are to the real deal.

That is what happened. Sorry about that. I thought I double checked
those but I missed at least one.

> I also want to see that all KVM modes have been tested (nVHE, hVHE, VHE,
> protected) before this gets picked up. Overall though taking this to
> stable seems like the right thing to do.

I'll make sure to test all those modes.

> Any reason why you've only done 6.6? The kernel was first aware of
> E2H=RES1 as far back as 5.13.

My reason for only doing 6.6 is when I tried to boot an L1 nested guest
with these patches on 6.1 I ran into another boot hang I haven't yet
debugged, and I didn't see the point in applying to 6.1 or earlier if
it's not enabling the behavior we want.

> Thanks,
> Oliver