From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 528BBC433FE for ; Tue, 29 Mar 2022 23:26:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240435AbiC2X2T (ORCPT ); Tue, 29 Mar 2022 19:28:19 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33704 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240323AbiC2X2O (ORCPT ); Tue, 29 Mar 2022 19:28:14 -0400 Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4858F186F8F for ; Tue, 29 Mar 2022 16:26:30 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id i11so7705700plg.12 for ; Tue, 29 Mar 2022 16:26:30 -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=FyT36mVFWHHmMaSNyNgttXeXWMR6GXiSODHEfHAzs+E=; b=ba0JAx2n4kkjoAQZJSqFJ69WwtL9z52owYSJ/KvYr9qfAEVMgIjcQHCDGPl6xQDA9F WoEhch7+l7DkM+nzyTxnQfvvtAqvX0ZgUlPGdQbz/iF99L0mJ8YzON6BFMsVkG3f0M6j ngfRX4ko8C/xzX0qHIRWhfrzT9fqYeJF1rkBO9TQ5vqXnGUf9qOlt7cUyvdwmXG8EQbJ D8mzrro8Jk5++JdkZPrPAEljZgGdhBE3F9w7DPw4v6duLNJ+IrMwnL+BCHDKfTXAE77T nWYiR792di2q+VxOaVkzWT+iuCGnfRCgI9r8MVIW6tZGcAVzKSgMZm0ClndvRxWcLRKx xlqA== 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=FyT36mVFWHHmMaSNyNgttXeXWMR6GXiSODHEfHAzs+E=; b=ZjbIG5DIg1wu72tc+UKD8USsDMU2osDTfUhfJDAqcupUUObbO6fQZdOMz4j5c/qRtp i1e63nDwADnzyqXqZALeeHQTgF3rH+rnvXAK26KmD1D8H68imACNAvUnFGkscTmVrUiY ZkrEmRfiFfOE/Qz2y8gW07paSgDr5+UsWnDnz3Bl5+WJaNpCVaXtjtsSCFiw+TvsU//q yuceTki/fL7VhmQAQtV0bcJ0uIzQhm8LJWbIQ9q+kH8407YOX07XItlhjs5o9PwPqus+ te4Px72tK6X47LybPiBwqeMoL0SPYyMHuR1Mjr521PEZsTpWV3oFwLQ+WJ6wVAQka25e uQ6g== X-Gm-Message-State: AOAM532KtJozv7gWTdt6r2s4FrBj6IwadU7NN1LT6qMtBZvnwxYH4Wic tloj5IDXfGr0B9IcFlPA3mPQ+g== X-Google-Smtp-Source: ABdhPJwnOb3NjFRKz1nmRlqh+ZvHsNMeDbIoEzibgQi4hxNEPlUdqkFegwqHxwwedq2s7qqe61C/mA== X-Received: by 2002:a17:902:d70e:b0:156:1b99:e909 with SMTP id w14-20020a170902d70e00b001561b99e909mr9037358ply.155.1648596389575; Tue, 29 Mar 2022 16:26:29 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id t10-20020a056a00138a00b004fa9c9fda44sm21128713pfg.89.2022.03.29.16.26.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Mar 2022 16:26:28 -0700 (PDT) Date: Tue, 29 Mar 2022 23:26:25 +0000 From: Sean Christopherson To: Like Xu Cc: Paolo Bonzini , kvm@vger.kernel.org, Jim Mattson , Wanpeng Li , Vitaly Kuznetsov , Joerg Roedel , linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 1/4] KVM: x86: Move kvm_ops_static_call_update() to x86.c Message-ID: References: <20220307115920.51099-1-likexu@tencent.com> <20220307115920.51099-2-likexu@tencent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 29, 2022, Sean Christopherson wrote: > On Mon, Mar 07, 2022, Like Xu wrote: > > From: Like Xu > > > > The kvm_ops_static_call_update() is defined in kvm_host.h. That's > > completely unnecessary, it should have exactly one caller, > > kvm_arch_hardware_setup(). As a prep match, move > > kvm_ops_static_call_update() to x86.c, then it can reference > > the kvm_pmu_ops stuff. > > > > Suggested-by: Sean Christopherson > > Signed-off-by: Like Xu > > --- > > Reviewed-by: Sean Christopherson Actually, I take that back. If we pass in @ops, and do some other minor tweaks along the way, then we can make kvm_pmu_ops static. I'll post a very compile-tested-only v3.1, trying to generate diffs against your series is going to be painful due to conflicts. The changes aren't big, just annoying. Below is the diff for this patch. Then in patch 2, kvm_ops_update() adds a call to kvm_pmu_ops_update(). Patch 3 just tweaks the call to use ops->pmu_ops instead of ops->runtime_ops->pmu_ops. Patch 4 becomes purely code shuffling (I think). --- arch/x86/kvm/x86.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 9cb8672aab92..99aa2d16845a 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -11595,8 +11595,10 @@ void kvm_arch_hardware_disable(void) drop_user_return_notifiers(); } -static inline void kvm_ops_static_call_update(void) +static inline void kvm_ops_update(struct kvm_x86_init_ops *ops) { + memcpy(&kvm_x86_ops, ops->runtime_ops, sizeof(kvm_x86_ops)); + #define __KVM_X86_OP(func) \ static_call_update(kvm_x86_##func, kvm_x86_ops.func); #define KVM_X86_OP(func) \ @@ -11623,8 +11625,7 @@ int kvm_arch_hardware_setup(void *opaque) if (r != 0) return r; - memcpy(&kvm_x86_ops, ops->runtime_ops, sizeof(kvm_x86_ops)); - kvm_ops_static_call_update(); + kvm_ops_update(ops); kvm_register_perf_callbacks(ops->handle_intel_pt_intr); base-commit: bd6b09f0754bea388a189d544ce11d83206579a2 --