Re: [PATCH 4/7] KVM: nVMX: Process each host MSR entry at most once when unwinding failed VM-Entry

[Sean Christopherson <seanjc@google.com>]

On Tue, Nov 03, 2026, Jim Mattson wrote:
> On Mon, Nov 2, 2026 at 4:10 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Mon, Nov 02, 2026, Jim Mattson wrote:
> > > KVM needs to do better.
> >
> > Meh, KVM is doing pretty darn good, all things considered.  Yeah, this code sucks.
> > But I'm not convinced the alternatives suck less.  We've gotten the set of missed
> > consistency checks down to effectively zero, module the TPR mess that I do test
> > by running warn_on_missed_cc=true.
> 
> I don't understand the TPR mess. The SDM says, "With the exception of
> fields corresponding to virtualized APIC registers (defined in Section
> 32.1.1), software may modify the virtual-APIC page referenced by the
> current VMCS of a logical processor in VMX non-root operation. (This
> is an exception to the general requirement given in Section 27.11.4.)"

Oh, I wasn't aware of that.  I agree, that gives us an "out" for vTPR, mostly.

> I would argue that this prohibits changes to VTPR between KVM's
> software VM-entry checks and hardware VM-entry to VMCS02. If the
> hardware VM-entry fails because VTPR has changed, section 27.11.4
> gives KVM the freedom to implement whatever "unpredictable behavior"
> we like. Yes, that probably does include loading MSR values from the
> VM-exit MSR-load list, but why complicate things?
> 
> Something like returning to userspace with
> KVM_INTERNAL_ERROR_EMULATION following a prohibited write to an active
> VTPR seems far easier--and cleaner. What am I missing?

My biggest concern is that KVM could kill L1 if an L2 coerces L1 into trying
VMLAUNCH/VMRESUME with invalid state.  KVM simply can't *know* that an unexpected
VM-Fail was due to the vTPR wrinkle.  Even if KVM re-checked state, it's possible
for the vTPR to be "restored" to a good value.

I.e. if KVM exits to userspace with KVM_INTERNAL_ERROR_EMULATION, then there's a
non-zero chance of a false positive.  KVM could exit to userspace if and only if
it caught the guest red-handed, but then we'd still need this horrific code for
the other cases, so that seems rather pointless.

warn_on_missed_cc helps, but in practice it can't detect cases for which we don't
have test coverage.  So *if* there was a bug that could be exploited by L2 to DoS
L1, odds are good warn_on_missed_cc didn't catch that hypothetical bug either.

Maybe with AI we can be 100% confident that KVM performs all of the VM-Fail
consistency checks?  Again, I'm not opposed to alternative approaches, but at the
same time I don't feel a sense of urgency.