Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp3177540pxb; Fri, 5 Nov 2021 11:02:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyM6BHw6HRGkWrlnWHPA9jxBwEQhRRXkMgLsBWyqgWHm508IItWvAfMPXHgJT/5VDDxhlOX X-Received: by 2002:a05:6638:27b:: with SMTP id x27mr6698625jaq.142.1636135371497; Fri, 05 Nov 2021 11:02:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1636135371; cv=none; d=google.com; s=arc-20160816; b=S/CqDlrXW46iT4l4kzWgALFHEjJpDIPFfjQJqvduK5EXHdyX8em37G9AxV2Oum6Cnl 8rwhDvUayTTxey/74i/3z7zbMb+oLN9xaiwC2BVRygscH5pOKz0aQVCs0kPR5rmakZD4 3ZNjLI+kN+eHDW2XNLLy0cW0dCbpB9VPc+HSr8sy8sbw6mLLe0BmxCUwnpZCYbtaLtyS lNZkKKEMqOF+PGIZ70xCBJQn0mrR34dTkQGnX8+uDiiK6GZxbsR6ZCMYEmc/5vi7yinl UJq/wbugqjBGtjptslZdAUjwDAJHEq3ZY3x0qJgG6t+suVWEMQ8oZ3mBt66ie9QE9xNj zRWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=BQvAChtGkGopxkASFYsDwmXZHmFC6+xDduRNBAB5e/o=; b=KUw+5n6BTaFG0jS5q0uADAAGpw+badHDOujRfslYqYam+DUD42X41Rq0i+nJ68GRo9 kvUcscOhaXTVncLuXSUDHAwFaecVEM+hr4yVyllzNTttQevhehDhSp9uG9CEwHEissNC WWd9InC8x5+aHqp8+MAEnDBS3r4To8Cxdg2IQGAXtSekpBv/vjWyHzd4WBFxsuGbJcaF 4SrslL/kRfK0hYhbE2FsjK1mfJW+7OvetaQ1dXpbT6Cxs3WbvaTI2C9NcXSoIbQxCtkw k7nOL5h77koYLK4erhWsGKYD8ouEWJkGqrb1b6v1TcT6YEgrt6T3r1R1Nu58/lg0GpVU //Cg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=thcOmkTS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p40si15306622jal.133.2021.11.05.11.02.38; Fri, 05 Nov 2021 11:02:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=thcOmkTS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233657AbhKEPv3 (ORCPT + 99 others); Fri, 5 Nov 2021 11:51:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45544 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232774AbhKEPv2 (ORCPT ); Fri, 5 Nov 2021 11:51:28 -0400 Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B8315C061205 for ; Fri, 5 Nov 2021 08:48:48 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id e65so8714586pgc.5 for ; Fri, 05 Nov 2021 08:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=BQvAChtGkGopxkASFYsDwmXZHmFC6+xDduRNBAB5e/o=; b=thcOmkTShq9Bj+tVLe+cwd6h3zcbAFPcJkJmzQdKhBNgKCY0vYLnO4CWPof9vab67N aPiQmqFs9U1sTyPYwAtbOcpQ9uQrua8mQHuNm2X2pcMfp9zzSEjuyqMNxm9BRNcZpK10 dTElB6AgVPcof8XDSgFPwjxa4XpeBuQVNbF2IH3OoyHYlOFMWnuN9x7Mre3fKmmVHSXy gOKVS3HJ+EyZe7nnuQT72uASNAUyZvP3OGgzuS8Nm9x+2XSfq+mYj8tA/evJa8mSmNnS +GvFivhfjdC5gr7ATBpR1XCdBRTNFOC92qcmnLfdSMi5s/NJiS1dDXekDmRiyqPAEgx7 jT7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=BQvAChtGkGopxkASFYsDwmXZHmFC6+xDduRNBAB5e/o=; b=CV8XUq/IdI/XRBgXLVPVTPM+ucMYyraiO4b6WYQvIRvfghubGtDcIl0Xa60DMDBPrk 9vWRcQmvGxqRg9ShEn3YriEeYylWM2ONBr6QNhIuVQibZffz0nxSOKpsQPKGWfJDKZBX 6i+EAUJw2hty4SpaJdNJSJNQAnhcGEvvgX7fbimL8SppJJLrWWa77YZ4S5BVa8ojJw4b mXA5pr7tMdRn3cczjUpMweKFPCH1dQobKFeiWv0JVHNvioc/B6z9fyY2jg4MiRMwsgNi aXM7nQGiwzQ3U6nSmffLFmu/1qp9H/mEf/jppIyPRK4mEguYqQymEKb3AKH/RjjFAMA8 zBSQ== X-Gm-Message-State: AOAM5336VzMzqqMs1ER6Lsx++tc6ezagLz9h0PK2IwrfFb3tdMt+MZNL Q+Q/VbFxdbk+WL7OBb+p0sSlfw== X-Received: by 2002:aa7:8883:0:b0:49f:9e4b:3047 with SMTP id z3-20020aa78883000000b0049f9e4b3047mr4187915pfe.48.1636127328031; Fri, 05 Nov 2021 08:48:48 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id lw1sm10743182pjb.38.2021.11.05.08.48.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Nov 2021 08:48:47 -0700 (PDT) Date: Fri, 5 Nov 2021 15:48:43 +0000 From: Sean Christopherson To: Like Xu Cc: Paolo Bonzini , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , 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 Message-ID: References: <20211103070310.43380-1-likexu@tencent.com> <20211103070310.43380-3-likexu@tencent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211103070310.43380-3-likexu@tencent.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > +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 > +#include > +#include > > #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 > + > +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 > +} 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 >