From: Sean Christopherson <seanjc@google.com>
To: Josh Poimboeuf <jpoimboe@kernel.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Mark Rutland <mark.rutland@arm.com>,
Jason Baron <jbaron@akamai.com>,
Steven Rostedt <rostedt@goodmis.org>,
Ard Biesheuvel <ardb@kernel.org>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [RFC][PATCH 5/5] x86/kvm: Simplify static call handling
Date: Fri, 10 Mar 2023 13:07:27 -0800 [thread overview]
Message-ID: <ZAucD8gHx8Xp8Dlb@google.com> (raw)
In-Reply-To: <432e4844ba65840af4a24f5e3f561aead867f6e7.1678474914.git.jpoimboe@kernel.org>
"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.
It's not strictly necessary, but I'm inclinded to keep KVM_X86_OP_OPTIONAL_RET0
around for documentation purposes. And if I could figure out the compiler magic
to make it work, a WARN/BUILD_BUG on the sizeof() the return type of a RET0
function being larger than sizeof(int). KVM encountered the fun that occurs on
a u64 return on 32-bit kernels due to "xor eax, eax" leaving garbage in edx.
next prev parent reply other threads:[~2023-03-10 21:07 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-10 20:31 [RFC][PATCH 0/5] Improve static call NULL handling Josh Poimboeuf
2023-03-10 20:31 ` [RFC][PATCH 1/5] static_call: Make NULL static calls consistent Josh Poimboeuf
2023-03-10 20:59 ` Peter Zijlstra
2023-03-11 1:20 ` Josh Poimboeuf
2023-03-12 15:17 ` Peter Zijlstra
2023-03-13 15:08 ` Sean Christopherson
2023-03-13 17:48 ` Sami Tolvanen
2023-03-14 1:58 ` Josh Poimboeuf
2023-03-14 10:06 ` Peter Zijlstra
2023-03-10 20:31 ` [RFC][PATCH 2/5] static_call: Make NULL static calls return 0 Josh Poimboeuf
2023-03-10 20:31 ` [RFC][PATCH 3/5] static_call: Remove static_call_cond() and its usages Josh Poimboeuf
2023-03-10 20:31 ` [RFC][PATCH 4/5] static_call: Remove DEFINE_STATIC_CALL_RET0() and its uses Josh Poimboeuf
2023-03-10 20:31 ` [RFC][PATCH 5/5] x86/kvm: Simplify static call handling Josh Poimboeuf
2023-03-10 21:07 ` Sean Christopherson [this message]
2023-03-10 21:13 ` Steven Rostedt
2023-03-10 21:29 ` Sean Christopherson
2023-03-10 22:23 ` Josh Poimboeuf
2023-03-10 21:09 ` [RFC][PATCH 0/5] Improve static call NULL handling Steven Rostedt
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=ZAucD8gHx8Xp8Dlb@google.com \
--to=seanjc@google.com \
--cc=ardb@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=jbaron@akamai.com \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox