Re: [PATCH] KVM: VMX: Explicitly track TDX VMs' root level instead of guessing it from CPUID

[Sean Christopherson <seanjc@google.com>]

On Wed, Aug 19, 2026, Rick P Edgecombe wrote:
> On Wed, 2026-08-19 at 11:45 -0700, Sean Christopherson wrote:
> > Hmm, for defense in depth, I want to explicitly check mirror_root_level,
> > because returning '0' would likely have dire consequences.  How about this?
> 
> :) Sure.
> 
> Yan and I were discussing what might be a new level of defense on MMU checking.
> We were basically trying to work out your thinking on some of the defensive
> patches lately. It seems there has also been a new level of activity on the bugs
> front so we want to adapt to any learnings you had. I actually planned to bring
> it up in PUCK, but...
> 
> Can you share any thoughts? Should we be more paranoid in general, or same as
> always? Or more specifically paranoid where issues hit?

The big learning I've had is that simply detecting bugs doesn't help protect the
host unless KVM also takes evasive action when the bug is detected.  E.g. a WARN
will (hopefully) be super helpful in root causing what went wrong, but it doesn't
do anything to mitigate the bug in real time.

A theme common to several (not all, but several) of the recent guest-exploitable
vulnerabilities is that KVM *did* have relevant sanity checks, but KVM didn't
actually do anything meaningful when a check failed and/or an assumption didn't
hold true.  It's not always possible/desirable to take evasive action (see below),
but in most cases it is.

Other than that, I don't think there's anything "new" per se, just a bit more of
a sense of urgency.  E.g. avoid BUG() and BUG_ON() unless there's a *very* high
probability the alternative is worse (this is why I said above that doing more
than WARNing may not be desirable).  If you fix a bug that could be applicable to
other code, look for ways to (practically) eliminate the potential source of bugs
(much of the guard() stuff falls into this category; the cleanup behavior makes
it a lot hard to end up with deadlock due to forgetting an unlock in a rare path).
And so on and so forth.

As for this exact sanity check, the reason why I think it's worth keeping is that
we've already messed it up once, the code pretty much only runs once per VM boot,
and if KVM configures the wrong level, the *best* case scenario is probably that
the host panics.  I.e. my past statements along the lines of "at some point we have
to not screw up" still hold true, but as with many kernel rules and guidlines, it
needs to be applied with a healthy dose of critical thinking.