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 09:30 -0700, Sean Christopherson wrote:
> > > > It comes down to a tradeoff. Should we prioritize code simplicity by dropping the function,
> > > > or keep it to explicitly catch this misbehaving guest corner case?
> > > 
> > > I think from KVM's perspective it doesn't want to help the guest behave
> > > correctly.
> > 
> > Uh, yes KVM does does.  KVM is responsible for emulating the APIC timer, isn't it?
> 
> Yea totally. We need to emulate the interface accurately. But we are kind of
> making up the contract after the fact. If the guest performs the wrong type of
> MSR write, should we make the contract that the VMM should help it catch it's
> mistake?
> 
> > 
> > > So we can ignore that I think. But it does really care to not define
> > > any specific guest ABI that it has to maintain. So tdx_has_emulated_msr() has
> > > some value there. And even more, it wants to not allow the guest to hurt the
> > > host.
> > > 
> > > On the latter point, another problem with deleting tdx_has_emulated_msr() is the
> > > current code path skips the checks done in the other MSR paths. So we would need
> > > to call some appropriate higher up MSR helper to protect the host? And that
> > > wades into the CPUID bit consistency issues.
> > > 
> > > So maybe... could we do a more limited version of the deletion where we allow
> > > all the APIC MSRs through? We'd have to check that it won't cause problems.
> > 
> > What?  No.  KVM can't get actually read/write most (all?) MSRs, allowing access
> > is far worse than returning an error, as for all intents and purposes KVM will
> > silently drop writes, and return garbage on reads.
> > 
> > > Failing that, we should maybe just explicitly list the ones TDX supports rather
> > > than the current way we define the APIC ones. As you mention below, it's not
> > > correct in other ways too so it could be more robust.
> > 
> > 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 think the below is a sane limitation, but doesn't lets KVM perfectly notify
> the guest when it screws up.
> 
> So the line would be to block MSRs that can never be emulated.
> 
> BTW, I've been treating this secret contract change as an arch mistake to at
> least not build on. It's a whole subject though... Let me know if you are
> interested in the details.