Re: [PATCH] x86/tdx: Enable #VE reduction feature

[Nikolay Borisov]

On 2.12.24 г. 9:24 ч., Kirill A. Shutemov wrote:
> Originally, #VE was defined as the TDX behavior in order to support
> paravirtualization of x86 features that can’t be virtualized by the TDX
> module. The intention is that if guest software wishes to use such a
> feature, it implements some logic to support this. This logic resides in
> the #VE exception handler it may work in cooperation with the host VMM.
>
> Theoretically, the guest TD’s #VE handler was supposed to act as a "TDX
> enlightenment agent" inside the TD. However, in practice, the #VE
> handler is simplistic:
>
>    - #VE on CPUID is handled by returning all-0 to the code which
>      executed CPUID. In many cases, an all-0 value is not the correct
>      value, and may cause improper operation.
>
>    - #VE on RDMSR is handled by requesting the MSR value from the host
>      VMM. This is prone to security issues since the host VMM is
>      untrusted. It may also be functionally incorrect in case the
>      expected operation is to paravirtualize some CPU functionality.
>
> Newer TDX module provides REDUCE_VE feature. When enabled, it
> drastically cuts cases when guests receives #VE on MSR and CPUID
> accesses. Behaviour of a specific MSR or CPUID leaf/sub-leaf is defined
> in the TDX spec.
>
> Enable REDUCE_VE. It brings TDX guest behaviour less odd, bring it
> closer to an architectural.
>
> Note that enabling of the feature doesn't eliminate need in #VE handler
> for CPUID and MSR accesses. Some MSRs still generate #VE (notably
> APIC-related) and kernel needs CPUID #VE handler to ask VMM for leafs in
> hypervisor range.
>
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx>

Reviewed-by: Nikolay Borisov <nik.borisov@xxxxxxxx>


<snip>