From: Sean Christopherson <seanjc@google.com>
To: Panayotis Katsaloulis <panayotis@panayotis.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: nVMX: Windows 11 with nested Hyper-V fails to boot when MBEC is exposed to L1 (7.2)
Date: Thu, 5 Nov 2026 15:45:05 -0800 [thread overview]
Message-ID: <au0VAbk3tXDy0p0W@google.com> (raw)
In-Reply-To: <58dcd595e3187d335e103a042d196cb7@panayotis.com>
On Thu, Nov 05, 2026, Panayotis Katsaloulis wrote:
> Hi,
>
> After updating the host from 7.1.13 to 7.2.9, a Windows 11 guest that
> runs its own hypervisor (VBS / Hyper-V, hypervisorlaunchtype Auto) no
> longer boots. It fails very early (no bugcheck, no minidump, bootstat
> not updated) and ends in Automatic Repair ("Your device ran into a
> problem and couldn't be repaired"). Startup Repair reports no root
> cause.
>
> Hiding MBEC from the guest is enough to make it boot again:
>
> -cpu host,migratable=on,vmx=on,vmx-mbec=off,hv-...
>
> Host:
> CPU: Intel Core i9-13900 (Raptor Lake)
> Kernel: 7.2.9 (distro kernel, Manjaro), kvm_intel nested=Y, mbec=Y
> QEMU: 11.1.2 (also reproduced with 11.1.1)
> libvirt: 12.8.0
> OVMF: edk2 202608, Secure Boot, swtpm 0.10.2 (TPM 2.0, CRB)
> Machine: pc-q35-9.2
Paolo was theorizing that might be related to Hyper-V expecting PFEC_SS to be
set[1] (Hyper-V appears to enable CET if and only if MBEC/GMET is available).
And IIRC, the host and guest hangs from an early bug report[2] were due to bugs
in the host's handling of hrtimers that affected only KVM VMX, but I don't think
we ever explained the outright failure to boot.
Paolo, do we have any patches to try out, or more concrete ideas/theories?
[1] https://lore.kernel.org/all/20261012165651.130826-1-pbonzini@redhat.com
[2] https://lore.kernel.org/all/85548beb-1486-40f9-beb4-632c78e3360b@proxmox.com
> Guest:
> Windows 11 24H2 (build 26100), UEFI + Secure Boot, VBS enabled,
> hypervisorlaunchtype Auto, 8 GiB, host-passthrough CPU.
> Hyper-V enlightenments: relaxed, vapic, spinlocks, vpindex, runtime,
> synic, stimer, frequencies, tlbflush, ipi, evmcs, avic, hypervclock.
>
> Results (host kernel 7.2.9 in all cases):
>
> vmx vmx-mbec hv-evmcs QEMU result
> on default on 11.1.2 fails (Automatic Repair)
> off n/a on 11.1.2 boots
> on default on 11.1.1 fails
> on off on 11.1.1 boots
> on default off 11.1.1 fails
>
> The same guest, with an identical QEMU command line (compared from the
> libvirt log; only fds/ids differ), last booted fine on 2026-10-23 on
> 7.1.13 with QEMU 11.1.1. So disabling eVMCS does not help, and QEMU
> and libvirt do not seem to be involved; the only difference that
> matters is whether MBEC is offered to L1.
>
> What I could not test:
> - 7.1.x with the exact same setup again (no longer installable here)
> - latest 7.2.y / 7.3.y
> - kvm_intel.mbec=0 (I expect it to behave like vmx-mbec=off)
>
> Someone else reports the same symptom (7.1.8 works, 7.2.x fails,
> Windows 11 26100 with nested Hyper-V), without a root cause:
> https://discuss.cachyos.org/t/windows-11-kvm-guest-with-nested-hyper-v-boot-loops-on-linux-cachyos-7-2-x-works-on-7-1-8/36134
>
> I can test patches or collect traces if that helps.
>
> Thanks,
> Panayotis
>
prev parent reply other threads:[~2026-11-05 23:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 18:42 nVMX: Windows 11 with nested Hyper-V fails to boot when MBEC is exposed to L1 (7.2) Panayotis Katsaloulis
2026-11-05 23:45 ` Sean Christopherson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=au0VAbk3tXDy0p0W@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=panayotis@panayotis.com \
--cc=pbonzini@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox