Re: [PATCH v10 11/11] x86/tdx: Handle CPUID via #VE

[Dave Hansen]

On 10/14/21 5:01 AM, Thomas Gleixner wrote:
>> The TDX module specification [1], section titled "CPUID Virtualization"
>> talks about a few more classes of CPUID handling. But, for the purposes
>> of this patch, the "handled transparently" CPUID leaves are all lumped
>> together because the guest handling is the same.
> What means 'for the purposes of this patch'? And I have no idea what's
> lumped together means either.

The TDX spec talks about a several classes of CPUID bit fields.  These
matter in terms of trust because some of the bits can be supplied by the
VMM.  The original changelog here tried to draw a distinction between
bits which can be supplied by the VMM ("as configured" in the spec) and
those that come directly from the hardware ("native" in the spec).

"Lumped together" means that although these cases are differentiated in
the spec, their differences are immaterial for the purposes of this patch.

I think I wrote this.  I think I was trying to write it at someone who
might be puzzling over the TDX spec and its table of CPUID leaves
wondering why the #VE handler doesn't have cases for lots of the classes
called out in the spec.

> #VE is either raised on CPUID leaf/sub-leaf combinations which are not
> part of the CPUID virtualization table or on request of the guest for
> all CPUID invocations (either Ring0 or Ring3 or both).

Yes.  This changelog should also include a note about the unconditional
#VE for all CPUID executions feature, noting that it is expected to be
disabled for ring0.

> So this patch implements the #VE handling for EXIT_REASON_CPUID by
> handing it through to the hypercall, which in turn lets the TDX module
> handle it by invoking the host VMM.
> 
> So unless the guest requested #VE on all CPUID invocations it won't see
> a #VE for the transparent leaf/sub-leaf combinations. #VE is raised
> for the VMM handled ones which goes through the hypercall, right?

Yep, that's a pretty succinct way to put it.