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

[Edgecombe, Rick P]

On Tue, 2026-04-28 at 09:30 -0700, Sean Christopherson wrote:
> > This patch looks good to me. But the rule for which MSRs should be emulated
> > by KVM for TDX is not very clear to me.
> 
> I would strongly prefer to not take this patch, and instead fix the guest. 
> This isn't some latent/pre-existing guest behavior, it's brand new
> functionality. I.e. Linux-as-a-TDX-guest broke itself.
> 
> More importantly from a guest security perspective, consuming
> MSR_IA32_PLATFORM_ID is actively dangerous.  E.g. it could allow the untrusted
> host to steer the guest's behavior with respect to feature detection and
> enablement.

I feel like you could make similar cases about a lot the VMM controlled MSRs.

> 
> And once KVM allows reads from MSR_IA32_PLATFORM_ID, there's no going back. 
> E.g. if the TDX-Module wants to emulate MSR_IA32_PLATFORM_ID, because there's
> an actual *need* to do so, then we're going to have a (minor) mess with KVM's
> ABI.

This is a problem with the bare metal KVM behavior too, and it's just super old?

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.

> 
> > Maybe we can document the rule here, if there is one. That would make it
> > much easier to tell whether future issues like this are guest regressions
> > or missing KVM handling.

Speaking in general now about TDX guest ABI, not about this specific MSR. I
agree it would be good to have some story about how this is supposed to work and
evolve. Similar to the CPUID bit stuff we are trying to clean up.

I'm also remembering the debate about what to do about the MTRR bit being forced
on, but not being able to apply the KVM solution (which got ripped out anyway)
to the S-EPT. Or the guest maxpfn thing, where we got the TDX module to add
CPUID bit support we needed. By default, we can try to make it so the TDX module
will, or will let us, faithfully match the normal x86 arch bit behavior.