[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZAuhQNS8mjRt1bOG@google.com>
Date: Fri, 10 Mar 2023 21:29:36 +0000
From: Sean Christopherson <seanjc@...gle.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Josh Poimboeuf <jpoimboe@...nel.org>, x86@...nel.org,
linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Mark Rutland <mark.rutland@....com>,
Jason Baron <jbaron@...mai.com>,
Ard Biesheuvel <ardb@...nel.org>,
Christophe Leroy <christophe.leroy@...roup.eu>,
Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [RFC][PATCH 5/5] x86/kvm: Simplify static call handling
On Fri, Mar 10, 2023, Steven Rostedt wrote:
> On Fri, 10 Mar 2023 13:07:27 -0800
> Sean Christopherson <seanjc@...gle.com> 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.
I don't think that provides the functionality KVM wants/needs. KVM only disallows
NULL updates for select mandatory hooks. For optional hooks, KVM needs to support
NULL updates in some capacity to handle the scenario where a vendor module is
reloaded with different settings, e.g. loading kvm_intel with enable_apicv=0 after
running with enable_apicv=1.
WARN_ON() a static_call_update(..., NULL) should be ok, but I believe KVM would
still need/want macro shenanigans, e.g.
#define __KVM_X86_OP(func) \
static_call_update(kvm_x86_##func,
kvm_x86_ops.func ? kvm_x86_ops.func : STATIC_CALL_NOP);
#define KVM_X86_OP(func) \
WARN_ON(!kvm_x86_ops.func); __KVM_X86_OP(func)
#define KVM_X86_OP_OPTIONAL __KVM_X86_OP
#define KVM_X86_OP_OPTIONAL_RET0(func) __KVM_X86_OP
Powered by blists - more mailing lists