Re: [PATCH] KVM: TDX: Fix APIC MSR ranges in tdx_has_emulated_msr()

[Sean Christopherson <seanjc@google.com>]

On Fri, Apr 03, 2026, Rick P Edgecombe wrote:
> On Fri, 2026-04-03 at 12:07 -0700, Sean Christopherson wrote:
> > > > No?  Don't we just want to allow access to MSRs that aren't accelerated? 
> > > > What the TDX-Module supports is largely irrelevant, I think.
> > > 
> > > Not sure if I might be missing the point here. As above, we don't have
> > > enough info to know which MSRs are accelerated. If the guest enabled #VE
> > > reduction, it changes which ones are accelerated and the VMM is not
> > > notified.
> > 
> > What does the "accleration" in that case?  Or does it reduce which ones are
> > accelerated?
> 
> I mean ones where wrmsr is handled by the TDX module instead of generating a #VE
> that gets morphed into TDVMCALL by the guest. Actually usually called "native",
> but I just reused your "accelerated" term from the mail.

It's neither.  Precision matters here, otherwise I can't follow along.  Accelerated
means the CPU virtualizes it without software involvement.  Native would mean the
guest has direct access to bare metal hardware.  IIUC, what's happening here is
that the TDX-Module is emulating x2APIC stuff.

> So... "Reduced #VE" (also called "VE reduction") reduces which things cause a
> #VE. The guest opts into it and the TDX module starts behaving differently. It's
> kind of grab bag of changes including changing CPUID behavior, which is another
> wrinkle. It was intended to fixup guest side TDX arch issues.

And KVM has no visilibity into which mode the guest has selected?  That's awful.

If KVM has no visiblity, then I don't see an option other than for KVM to advertise
and emulate what it can at all times, and it becomes the guest's responsibility
to not screw up.  I guess it's not really any different from not trying to use
MMIO accesses after switching to x2APIC mode.