diff options
| author | Sean Christopherson <seanjc@google.com> | 2026-10-27 11:59:17 -0700 |
|---|---|---|
| committer | Paolo Bonzini <pbonzini@redhat.com> | 2026-11-02 12:49:18 -0500 |
| commit | c33ef9d334059f7cb167569ed7b4779752fe4425 (patch) | |
| tree | 7db6f7f7a4338b1645487e60e0f98c546ec80770 /scripts/basic/split-include.c | |
| parent | ae85ac25eb671d174811cc3101549448671fd505 (diff) | |
| download | linux-c33ef9d334059f7cb167569ed7b4779752fe4425.tar.gz linux-c33ef9d334059f7cb167569ed7b4779752fe4425.zip | |
KVM: nVMX: Process each host MSR entry at most once when unwinding failed VM-Entry
Add a missing "break" in the inner for-loop of the open coded mess that
unwinds MSRs back to the pre-VM-Enter state when VMLAUNCH/VMRESUME VM-Fails
due to a consistency check that is caught by hardware but missed by KVM.
I.e. move on to the next MSR in the VM-Entry load list after performing a
write using a value found in the VM-Exit load list. Processing *every*
matching entry in the VM-Exit load list makes the processing quadratic,
which is problematic if the load lists are full of MSRs that are expensive
to emulate. E.g. writing APIC_BASE triggers kvm_recalculate_apic_map() and
a whole pile of unnecessary work.
Functionally, arbitrarily restoring the value of the first matching entry
is "fine", because none of this is architecturally correct: the load lists
are never supposed to have been used in the first place. In practice, it's
likely a moot point as no well-behaved VMM will have multiple, diverging
entries in the load lists.
Fixes: bd18bffca353 ("KVM: nVMX: restore host state in nested_vmx_vmexit for VMFail")
Cc: stable@vger.kernel.org
Cc: David Woodhouse <dwmw2@infradead.org>
Reported-by: Stefan Teodorescu <fane@google.com>
Suggested-by: Stefan Teodorescu <fane@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-ID: <20261027185917.1478906-1-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'scripts/basic/split-include.c')
0 files changed, 0 insertions, 0 deletions
