Re: [PATCH 1/2] KVM: TDX: Allow TDs to read MSR_IA32_PLATFORM_ID

[Edgecombe, Rick P]

On Tue, 2026-04-28 at 11:44 -0700, Sean Christopherson wrote:
> > This is a problem with the bare metal KVM behavior too, and it's just super
> > old?
> 
> No?  Oh, I see what you're asking.  

I mean that KVM has hacked ABI around this already. So here we just don't do it
again.

> I'm mostly concerned about the host side of things.  The problem with TDX is
> that a TDX-Module update could effectively
> change KVM's behavior, i.e. if the TDX-Module decides it needs to emulate
> PLATFORM_ID for whatever reason.

We have similar problems with CPUID bits.

Besides that, the guest can actually change some MSR handling. The reduced #VE
thing.

>   So not only would KVM need to enumerate to userspace that the MSR is
> supported/emulated for TDX guests, KVM would also need to differentiate
> between emulated by KVM and emulated by the TDX-Module.

The KVM supported and TDX-Module supported ones are already effectively separate
things. And the guest can even know which one it is accessing.

I agree we can just not support this MSR for now, but I think Chao is right we
need a plan for this. I don't have any clear and confident ideas.

I'm seeing a lot of parrallels to the CPUID bit cleanup effort. Binbin and the
team did a bunch of pondering to find the right line between opt-ins everywhere
and avoiding backwards ABI issues. We probably need to do this here too.

> 
> > For TDX, hmm. I guess the standard thing to do in order to avoid creating a
> > KVM ABI problems is just match the arch behavior. But for TDs, it is a very
> > special type of VM. The special TDX guest things can't work on bare metal.
> > Furthermore, guest opt ins can change what arch is even supposed to be
> > virtualized. So the normal KVM default thing to do doesn't always fit.
> > 
> > So instead we will just virtualize as little as possible to keep Linux guest
> > running? Ok.
> 
> Yeah, and the sequence of events matters.  Most of KVM's half-hearted
> emulation of random MSRs exists because KVM needed to be able to run existing
> kernels. But once KVM (and other hypervisors) existed, kernels learned to run
> as guests (and hardware vendors largely did a better job of explicitly
> enumerating MSRs and whatnot), and so the need to throw hacks into KVM mostly
> went away.

So now we don't want to throw hacks in again. But we (Intel TDX folks) need to
make sure TDX arch makes it so there isn't a pressure for hacks too.