If I enable SMP and an OVMF firmware in my VM, QEMU either hangs at boot or dies with the error message: KVM: entry failed, hardware error 0x80000021 A minimal QEMU command line to repro is: qemu-system-x86_64 -enable-kvm -smp cpus=2 -drive if=pflash,format=raw,file=OVMF.fd Running host kernel 4.4.6, and I bisected the failure to OVMF commit 94941c8: UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs Doing some debugging, I built the latest OVMF from git and bisected the failure to kernel commit (merged for 4.2rc1) d28bc9d: KVM: x86: INIT and reset sequences are different To clarify, the failing config is: Host kernel d28bc9d+ (~4.2rc1), OVMF 94941c8+, and SMP enabled Working configs are: Host kernels 4.1-4.4, OVMF tip, and SMP disabled Host kernels 4.1-4.4, SeaBIOS (instead of OVMF), and SMP enabled Host kernel 4.1, OVMF tip, and SMP enabled Host kernels 4.1-4.4, OVMF prior to 94941c8, and SMP enabled The host system is running a quad-core Intel Penryn CPU (which supports VMX but not EPT). Per OVMF dev Laszlo Ersek, the failure is related to lacking EPT support.
Created attachment 213331 [details] Partial revert of d28bc9d for current KVM. Does the guest boot if you apply the attached patch on top of current KVM? And if you discard the "init_event = false;" hunk from the patch? Thanks.
I tested against mainline 4.4.7, is that ok? Otherwise, by "current KVM" do you mean from git://git.kernel.org/pub/scm/virt/kvm/kvm.git ? With the full patch applied, the guest failed to boot. With just the bottom hunk applied, the guest booted.
4.4.7 is ok, thank you for testing! Yes, current KVM is that one. Latest Linus' tree counts too. The patch is bad as I erroneously didn't revert the "vmx->vcpu.arch.cr0 = cr0;" line and cr0 is not initialized there ... the shame made me build OVMF and I tried to reproduce on latest unpatched KVM and it worked fine -- does it work for you too? Thanks.
I built from commit 5e1b59a in kvm/master and the guest was unable to boot.
Radim, am I right to think that this is fixed by commit f24632475d4f in v4.7-rc1, and by commit 3bae61327149 in v4.6.1? If that's the case, we should probably close this report. Thanks! Laszlo
Yes, you're right.
I confirmed it's working on 4.6.2 Thanks!