Re: [RFC][PATCH 5/5] x86/kvm: Simplify static call handling

[Steven Rostedt]

On Fri, 10 Mar 2023 13:07:27 -0800
Sean Christopherson <seanjc@xxxxxxxxxx> wrote:

> "KVM: x86:" please, "x86/kvm" is for guest-side changes.
> 
> On Fri, Mar 10, 2023, Josh Poimboeuf wrote:
> > diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> > index 1dfba499d3e5..612531e1c478 100644
> > --- a/arch/x86/include/asm/kvm_host.h
> > +++ b/arch/x86/include/asm/kvm_host.h
> > @@ -1789,8 +1789,6 @@ extern struct kvm_x86_ops kvm_x86_ops;
> >  
> >  #define KVM_X86_OP(func) \
> >  	DECLARE_STATIC_CALL(kvm_x86_##func, *(((struct kvm_x86_ops *)0)->func));
> > -#define KVM_X86_OP_OPTIONAL KVM_X86_OP
> > -#define KVM_X86_OP_OPTIONAL_RET0 KVM_X86_OP
> >  #include <asm/kvm-x86-ops.h>
> >  
> >  int kvm_x86_vendor_init(struct kvm_x86_init_ops *ops);
> > diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
> > index 6accb46295a3..5f7f860c5f17 100644
> > --- a/arch/x86/kvm/pmu.c
> > +++ b/arch/x86/kvm/pmu.c
> > @@ -77,20 +77,15 @@ static struct kvm_pmu_ops kvm_pmu_ops __read_mostly;
> >  #define KVM_X86_PMU_OP(func)					     \
> >  	DEFINE_STATIC_CALL_NULL(kvm_x86_pmu_##func,			     \
> >  				*(((struct kvm_pmu_ops *)0)->func));
> > -#define KVM_X86_PMU_OP_OPTIONAL KVM_X86_PMU_OP
> >  #include <asm/kvm-x86-pmu-ops.h>
> >  
> >  void kvm_pmu_ops_update(const struct kvm_pmu_ops *pmu_ops)
> >  {
> >  	memcpy(&kvm_pmu_ops, pmu_ops, sizeof(kvm_pmu_ops));
> >  
> > -#define __KVM_X86_PMU_OP(func) \
> > -	static_call_update(kvm_x86_pmu_##func, kvm_pmu_ops.func);
> >  #define KVM_X86_PMU_OP(func) \
> > -	WARN_ON(!kvm_pmu_ops.func); __KVM_X86_PMU_OP(func)  
> 
> I would much prefer to keep KVM mostly as-is, specifically so that we don't lose
> this WARN_ON() that guards against a vendor module neglecting to implement a
> mandatory callback.  This effectively gives KVM "full" protection against consuming
> an unexpectedly-NULL function pointer.

As in my reply to patch 0/5, I suggested that static_call_update(NULL)
would trigger a WARN_ON() always. Then this could be cleaned up and still
get that warning.

-- Steve