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

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Fri, 2026-04-03 at 16:07 -0700, Sean Christopherson wrote:
> > 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.  

Oh, sorry. 

> IIUC, what's happening here is that the TDX-Module is emulating x2APIC stuff.

I'll stick to this language. The tdx docs call them differently of course.
"native" there is about #VE or not. So I can talk about it with respect to VE or
!VE.

> 
> > 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.

Yea, on both accounts. So where we are at with this is, starting to reject
changes that build on the pattern. We haven't gone so far as to ask for a
feature to notify the host of the guest opt-ins. But I wouldn't say we have a
grand design in mind either. If you have any clarity, please feel free to drop a
quotable.

> 
> 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.

Like your diff? Expose any MSRs that might be emulated in the TDX paradigm. But
don't expose all MSRs that KVM supports.