All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Like Xu <like.xu.linux@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
	Vitaly Kuznetsov <vkuznets@redhat.com>,
	Wanpeng Li <wanpengli@tencent.com>,
	Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] KVM: x86: Introduce definitions to support static calls for kvm_pmu_ops
Date: Fri, 5 Nov 2021 15:48:43 +0000	[thread overview]
Message-ID: <YYVSW4Jr75oJ6MhC@google.com> (raw)
In-Reply-To: <20211103070310.43380-3-likexu@tencent.com>

On Wed, Nov 03, 2021, Like Xu wrote:
> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
> index 0db1887137d9..b6f08c719125 100644
> --- a/arch/x86/kvm/pmu.c
> +++ b/arch/x86/kvm/pmu.c
> @@ -50,6 +50,13 @@
>  struct kvm_pmu_ops kvm_pmu_ops __read_mostly;
>  EXPORT_SYMBOL_GPL(kvm_pmu_ops);
>  
> +#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_NULL	KVM_X86_PMU_OP

More of a question for the existing code, what's the point of KVM_X86_OP_NULL?
AFAICT, it always resolves to KVM_X86_OP.  Unless there's some magic I'm missing,
I vote we remove KVM_X86_OP_NULL and then not introduce KVM_X86_PMU_OP_NULL.
And I'm pretty sure it's useless, e.g. get_cs_db_l_bits is defined with the NULL
variant, but it's never NULL and its calls aren't guarded with anything.  And if
KVM_X86_OP_NULL is intended to aid in documenting behavior, it's doing a pretty
miserable job of that :-)

> +#include <asm/kvm-x86-pmu-ops.h>
> +EXPORT_STATIC_CALL_GPL(kvm_x86_pmu_is_valid_msr);

I'll double down on my nVMX suggestion so that this export can be avoided.

>  static void kvm_pmi_trigger_fn(struct irq_work *irq_work)
>  {
>  	struct kvm_pmu *pmu = container_of(irq_work, struct kvm_pmu, irq_work);
> diff --git a/arch/x86/kvm/pmu.h b/arch/x86/kvm/pmu.h
> index b2fe135d395a..e5550d4acf14 100644
> --- a/arch/x86/kvm/pmu.h
> +++ b/arch/x86/kvm/pmu.h
> @@ -3,6 +3,8 @@
>  #define __KVM_X86_PMU_H
>  
>  #include <linux/nospec.h>
> +#include <linux/static_call_types.h>
> +#include <linux/static_call.h>
>  
>  #define vcpu_to_pmu(vcpu) (&(vcpu)->arch.pmu)
>  #define pmu_to_vcpu(pmu)  (container_of((pmu), struct kvm_vcpu, arch.pmu))
> @@ -45,6 +47,19 @@ struct kvm_pmu_ops {
>  	void (*cleanup)(struct kvm_vcpu *vcpu);
>  };
>  
> +#define	KVM_X86_PMU_OP(func)	\
> +	DECLARE_STATIC_CALL(kvm_x86_pmu_##func, *(((struct kvm_pmu_ops *)0)->func))
> +#define	KVM_X86_PMU_OP_NULL	KVM_X86_PMU_OP
> +#include <asm/kvm-x86-pmu-ops.h>
> +
> +static inline void kvm_pmu_ops_static_call_update(void)
> +{
> +#define	KVM_X86_PMU_OP(func)	\
> +	static_call_update(kvm_x86_pmu_##func, kvm_pmu_ops.func)
> +#define	KVM_X86_PMU_OP_NULL	KVM_X86_PMU_OP
> +#include <asm/kvm-x86-pmu-ops.h>
> +}

As alluded to in patch 01, I'd prefer these go in kvm_ops_static_call_update()
to keep the static call magic somewhat contained.

> +
>  static inline u64 pmc_bitmask(struct kvm_pmc *pmc)
>  {
>  	struct kvm_pmu *pmu = pmc_to_pmu(pmc);
> -- 
> 2.33.0
> 

  reply	other threads:[~2021-11-05 15:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-03  7:03 [PATCH 0/3] Use static_call for kvm_pmu_ops Like Xu
2021-11-03  7:03 ` [PATCH 1/3] KVM: x86: Copy kvm_pmu_ops by value to eliminate layer of indirection Like Xu
2021-11-05 15:30   ` Sean Christopherson
2021-11-05 15:36     ` Sean Christopherson
2021-11-08  9:26       ` Like Xu
2021-11-08  9:23     ` Like Xu
2021-11-03  7:03 ` [PATCH 2/3] KVM: x86: Introduce definitions to support static calls for kvm_pmu_ops Like Xu
2021-11-05 15:48   ` Sean Christopherson [this message]
2021-11-08  9:31     ` Like Xu
2021-11-08 15:41       ` Sean Christopherson
2021-11-03  7:03 ` [PATCH 3/3] KVM: x86: Use static calls to reduce kvm_pmu_ops overhead Like Xu
2021-11-03 12:08   ` Yao Yuan
2021-11-04  8:14     ` Like Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YYVSW4Jr75oJ6MhC@google.com \
    --to=seanjc@google.com \
    --cc=bp@alien8.de \
    --cc=jmattson@google.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=like.xu.linux@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.