[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <518a71a9-011f-456c-bc99-639a5d69c144@linux.intel.com>
Date: Wed, 12 Feb 2025 13:51:33 +0800
From: Binbin Wu <binbin.wu@...ux.intel.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: pbonzini@...hat.com, kvm@...r.kernel.org, rick.p.edgecombe@...el.com,
kai.huang@...el.com, adrian.hunter@...el.com, reinette.chatre@...el.com,
xiaoyao.li@...el.com, tony.lindgren@...el.com, isaku.yamahata@...el.com,
yan.y.zhao@...el.com, chao.gao@...el.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 09/17] KVM: TDX: Handle SMI request as !CONFIG_KVM_SMM
On 2/12/2025 9:47 AM, 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".
Yes.
>
> 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.
Thanks for the suggestion!
Since the changes will be across multiple sections of TDX KVM support,
instead of modifying them individually, are you OK if we do it in a separate
cleanup patch?
[...]
Powered by blists - more mailing lists