Re: [PATCH v2 09/17] KVM: TDX: Handle SMI request as !CONFIG_KVM_SMM

["Huang, Kai" <kai.huang@intel.com>]

On 12/02/2025 2:47 pm, Sean Christopherson wrote:
> On Tue, Feb 11, 2025, Binbin Wu wrote:
>> +#ifdef CONFIG_KVM_SMM
>> +static int vt_smi_allowed(struct kvm_vcpu *vcpu, bool for_injection)
>> +{
>> +	if (KVM_BUG_ON(is_td_vcpu(vcpu), vcpu->kvm))
>> +		return false;
> 
> Nit, while the name suggests a boolean return, the actual return in -errno/0/1,
> i.e. this should be '0', not "false".
> 
> A bit late to be asking this, but has anyone verified all the KVM_BUG_ON() calls
> are fully optimized out when CONFIG_KVM_INTEL_TDX=n?
> 
> /me rummages around
> 
> Sort of.  The KVM_BUG_ON()s are all gone, but sadly a stub gets left behind.  Not
> the end of the world since they're all tail calls, but it's still quite useless,
> especially when using frame pointers.
> 
> Aha!  Finally!  An excuse to macrofy some of this!
> 
> Rather than have a metric ton of stubs for all of the TDX variants, simply omit
> the wrappers when CONFIG_KVM_INTEL_TDX=n.  Quite nearly all of vmx/main.c can go
> under a single #ifdef.  That eliminates all the silly trampolines in the generated
> code, and almost all of the stubs.
> 
> Compile tested only, and needs to be chunked up. E.g. switching to the
> right CONFIG_xxx needs to be done elsewhere, ditto for moving the "pre restore"
> function to posted_intr.c.

AFAICT, if we export kvm_ops_update(), or kvm_x86_ops directly to 
kvm-intel then we can even take a further step to just set those 
callbacks back to vmx_xx() again if KVM determines TDX cannot be 
supported at module loading time.  And this can cover 
!CONFIG_KVM_INTEL_TDX as well.