Re: "Paravisor" Feature Enumeration

[Edgecombe, Rick P]

On Tue, 2026-01-06 at 01:44 +0000, Andrew Cooper wrote:
> I agree that it seems like "just" an enumeration problem, but despite
> attending the presentation and rereading the slides, I'm still not clear
> on the precise scope.
> 
> Are we saying that, inside an opaque blob that a customer provides to a
> CSP to run we might have:
> 
> * a paravisor and an unaware OS, or
> * svsm and a fully-aware OS, or
> * something in-between these two.
> 
> and we're looking a way to describe which piece of the interior stack
> owns which capability/service?
> 
> If so, it can't come in from the outside; given that it's the capability
> enumeration, there's a chicken/egg problem with verifying the integrity.
> 
> It seems like it needs to be produced by whatever the first code to run
> is, after gathering capabilities in a vendor-specific way, and deciding
> which services it wants to provide, and which to delegate.
> 
> And if so, then it definitely cannot be in CPUID because that needs to
> be fixed from prior to the guest starting to run, and doesn't express
> dynamic properties of the system[*]

For TDX, the guest has some control of the CPUID bits. Both via #VE
interception, and poking at the TDX module guest side interfaces to change which
CPUID leafs generate a #VE.

This is indeed a complication for "the outside". It handles some MSRs accesses
that depend on the CPUID config which it doesn't have final visibility into.

I would like to see less of that in the future. But marking off a certain range
of leafs to be handled by the paravisor/SVSM and that KVM/outside just ignores
seems better than current situation we already have at least. Not to dismiss the
other points.