From: Sean Christopherson <seanjc@google.com>
To: Raghavendra Rao Ananta <rananta@google.com>
Cc: Shaoqin Huang <shahuang@redhat.com>,
Gavin Shan <gshan@redhat.com>,
Oliver Upton <oliver.upton@linux.dev>,
Marc Zyngier <maz@kernel.org>, James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Huacai Chen <chenhuacai@kernel.org>,
Zenghui Yu <yuzenghui@huawei.com>,
Anup Patel <anup@brainfault.org>,
Atish Patra <atishp@atishpatra.org>,
Jing Zhang <jingzhangos@google.com>,
Reiji Watanabe <reijiw@google.com>,
Colton Lewis <coltonlewis@google.com>,
David Matlack <dmatlack@google.com>,
Fuad Tabba <tabba@google.com>,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-mips@vger.kernel.org, kvm-riscv@lists.infradead.org,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org
Subject: Re: [PATCH v8 02/14] KVM: Declare kvm_arch_flush_remote_tlbs() globally
Date: Thu, 10 Aug 2023 16:04:37 -0700 [thread overview]
Message-ID: <ZNVtBQvjM45tmbce@google.com> (raw)
In-Reply-To: <CAJHc60w0By2Q+PCsfwReGXsN5zf5k1ww3Ov4m9Eb-pFH-UKBDg@mail.gmail.com>
On Thu, Aug 10, 2023, Raghavendra Rao Ananta wrote:
> On Thu, Aug 10, 2023 at 3:20 PM Sean Christopherson <seanjc@google.com> wrote:
> > On Thu, Aug 10, 2023, Raghavendra Rao Ananta wrote:
> > > After doing some experiments, I think it works because of the order in
> > > which the inline-definition and the declaration are laid out. If the
> > > 'inline' part of the function comes first and then the declaration, we
> > > don't see any error. However if the positions were reversed, we would
> > > see an error. (I'm not sure what the technical reason for this is).
> > >
> > > Just to be safe, I can move the definition to arch/x86/kvm/mmu/mmu.c
> > > as a non-inline function.
> >
> > No need, asm/kvm_host.h _must_ be included before the declaration, otherwise the
> > declaration wouldn't be made because __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS wouldn't
> > be defined. I.e. we won't run into issues where the non-static declaration comes
> > before the static inline definition.
> >
> > C99 explicitly covers this case:
> >
> > 6.2.2 Linkages of identifiers
> >
> > ...
> >
> > If the declaration of a file scope identifier for an object or a function contains the storage-
> > class specifier static, the identifier has internal linkage.
> >
> > For an identifier declared with the storage-class specifier extern in a scope in which a
> > prior declaration of that identifier is visible if the prior declaration specifies internal or
> > external linkage, the linkage of the identifier at the later declaration is the same as the
> > linkage specified at the prior declaration. If no prior declaration is visible, or if the prior
> > declaration specifies no linkage, then the identifier has external linkage.
> >
> > In short, because the "static inline" declared internal linkage first, it wins.
> Thanks for sharing this! I can keep the 'static inline' definition as
> is then. However, since a later patch (patch-05/14) defines
> kvm_arch_flush_remote_tlbs_range() in arch/x86/kvm/mmu/mmu.c, do you
> think we can move this definition to the .c file as well for
> consistency?
We "can", but I don't see any reason to do so. Trying to make helpers consistently
inline or not is usually a fools errand. And in this case, I'd actually rather go
the opposite direction and make the range variant an inline.
Ha! And I can justify that with minimal effort. The below makes the helper a
straight passthrough for CONFIG_HYPERV=n builds, at which point I think it makes
sense for it to be inline.
If it won't slow your series down even more, any objection to sliding the below
patch in somewhere before patch 5? And then add a patch to inline the range-based
helper?
Disclaimer: compile tested only.
---
From: Sean Christopherson <seanjc@google.com>
Date: Thu, 10 Aug 2023 15:58:53 -0700
Subject: [PATCH] KVM: x86/mmu: Declare flush_remote_tlbs{_range}() hooks iff
HYPERV!=n
Declare the kvm_x86_ops hooks used to wire up paravirt TLB flushes when
running under Hyper-V if and only if CONFIG_HYPERV!=n. Wrapping yet more
code with IS_ENABLED(CONFIG_HYPERV) eliminates a handful of conditional
branches, and makes it super obvious why the hooks *might* be valid.
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/include/asm/kvm-x86-ops.h | 2 ++
arch/x86/include/asm/kvm_host.h | 4 ++++
arch/x86/kvm/mmu/mmu.c | 6 ++++++
3 files changed, 12 insertions(+)
diff --git a/arch/x86/include/asm/kvm-x86-ops.h b/arch/x86/include/asm/kvm-x86-ops.h
index 13bc212cd4bc..6bc1ab0627b7 100644
--- a/arch/x86/include/asm/kvm-x86-ops.h
+++ b/arch/x86/include/asm/kvm-x86-ops.h
@@ -54,8 +54,10 @@ KVM_X86_OP(set_rflags)
KVM_X86_OP(get_if_flag)
KVM_X86_OP(flush_tlb_all)
KVM_X86_OP(flush_tlb_current)
+#if IS_ENABLED(CONFIG_HYPERV)
KVM_X86_OP_OPTIONAL(flush_remote_tlbs)
KVM_X86_OP_OPTIONAL(flush_remote_tlbs_range)
+#endif
KVM_X86_OP(flush_tlb_gva)
KVM_X86_OP(flush_tlb_guest)
KVM_X86_OP(vcpu_pre_run)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 60d430b4650f..04fc80112dfe 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1604,9 +1604,11 @@ struct kvm_x86_ops {
void (*flush_tlb_all)(struct kvm_vcpu *vcpu);
void (*flush_tlb_current)(struct kvm_vcpu *vcpu);
+#if IS_ENABLED(CONFIG_HYPERV)
int (*flush_remote_tlbs)(struct kvm *kvm);
int (*flush_remote_tlbs_range)(struct kvm *kvm, gfn_t gfn,
gfn_t nr_pages);
+#endif
/*
* Flush any TLB entries associated with the given GVA.
@@ -1814,6 +1816,7 @@ static inline struct kvm *kvm_arch_alloc_vm(void)
#define __KVM_HAVE_ARCH_VM_FREE
void kvm_arch_free_vm(struct kvm *kvm);
+#if IS_ENABLED(CONFIG_HYPERV)
#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB
static inline int kvm_arch_flush_remote_tlb(struct kvm *kvm)
{
@@ -1823,6 +1826,7 @@ static inline int kvm_arch_flush_remote_tlb(struct kvm *kvm)
else
return -ENOTSUPP;
}
+#endif
#define kvm_arch_pmi_in_guest(vcpu) \
((vcpu) && (vcpu)->arch.handling_intr_from_guest)
diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index 9e4cd8b4a202..0189dfecce1f 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -271,18 +271,24 @@ static inline unsigned long kvm_mmu_get_guest_pgd(struct kvm_vcpu *vcpu,
static inline bool kvm_available_flush_remote_tlbs_range(void)
{
+#if IS_ENABLED(CONFIG_HYPERV)
return kvm_x86_ops.flush_remote_tlbs_range;
+#else
+ return false;
+#endif
}
void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn,
gfn_t nr_pages)
{
+#if IS_ENABLED(CONFIG_HYPERV)
int ret = -EOPNOTSUPP;
if (kvm_x86_ops.flush_remote_tlbs_range)
ret = static_call(kvm_x86_flush_remote_tlbs_range)(kvm, start_gfn,
nr_pages);
if (ret)
+#endif
kvm_flush_remote_tlbs(kvm);
}
base-commit: bc9e68820274c025840d3056d63f938d74ca35bb
--
next prev parent reply other threads:[~2023-08-10 23:04 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-08 23:13 [PATCH v8 00/14] KVM: arm64: Add support for FEAT_TLBIRANGE Raghavendra Rao Ananta
2023-08-08 23:13 ` [PATCH v8 01/14] KVM: Rename kvm_arch_flush_remote_tlb() to kvm_arch_flush_remote_tlbs() Raghavendra Rao Ananta
2023-08-08 23:13 ` [PATCH v8 02/14] KVM: Declare kvm_arch_flush_remote_tlbs() globally Raghavendra Rao Ananta
2023-08-09 4:00 ` Gavin Shan
2023-08-09 16:38 ` Raghavendra Rao Ananta
2023-08-10 12:26 ` Shaoqin Huang
2023-08-10 20:54 ` Raghavendra Rao Ananta
2023-08-10 22:20 ` Sean Christopherson
2023-08-10 22:34 ` Raghavendra Rao Ananta
2023-08-10 23:04 ` Sean Christopherson [this message]
2023-08-11 4:09 ` Raghavendra Rao Ananta
2023-08-11 3:18 ` Shaoqin Huang
2023-08-08 23:13 ` [PATCH v8 03/14] KVM: arm64: Use kvm_arch_flush_remote_tlbs() Raghavendra Rao Ananta
2023-08-09 4:10 ` Gavin Shan
2023-08-08 23:13 ` [PATCH v8 04/14] KVM: Remove CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL Raghavendra Rao Ananta
2023-08-09 4:11 ` Gavin Shan
2023-08-10 9:04 ` Philippe Mathieu-Daudé
2023-08-08 23:13 ` [PATCH v8 05/14] KVM: Allow range-based TLB invalidation from common code Raghavendra Rao Ananta
2023-08-09 6:09 ` Gavin Shan
2023-08-09 16:41 ` Raghavendra Rao Ananta
2023-08-08 23:13 ` [PATCH v8 06/14] KVM: Move kvm_arch_flush_remote_tlbs_memslot() to " Raghavendra Rao Ananta
2023-08-08 23:13 ` [PATCH v8 07/14] arm64: tlb: Refactor the core flush algorithm of __flush_tlb_range Raghavendra Rao Ananta
2023-08-08 23:13 ` [PATCH v8 08/14] arm64: tlb: Implement __flush_s2_tlb_range_op() Raghavendra Rao Ananta
2023-08-11 3:16 ` Shaoqin Huang
2023-08-08 23:13 ` [PATCH v8 09/14] KVM: arm64: Implement __kvm_tlb_flush_vmid_range() Raghavendra Rao Ananta
2023-08-09 0:43 ` Gavin Shan
2023-08-11 3:15 ` Shaoqin Huang
2023-08-08 23:13 ` [PATCH v8 10/14] KVM: arm64: Define kvm_tlb_flush_vmid_range() Raghavendra Rao Ananta
2023-08-08 23:13 ` [PATCH v8 11/14] KVM: arm64: Implement kvm_arch_flush_remote_tlbs_range() Raghavendra Rao Ananta
2023-08-10 1:40 ` kernel test robot
2023-08-11 3:03 ` Shaoqin Huang
2023-08-08 23:13 ` [PATCH v8 12/14] KVM: arm64: Flush only the memslot after write-protect Raghavendra Rao Ananta
2023-08-08 23:13 ` [PATCH v8 13/14] KVM: arm64: Invalidate the table entries upon a range Raghavendra Rao Ananta
2023-08-08 23:13 ` [PATCH v8 14/14] KVM: arm64: Use TLBI range-based intructions for unmap Raghavendra Rao Ananta
2023-08-11 3:13 ` Shaoqin Huang
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=ZNVtBQvjM45tmbce@google.com \
--to=seanjc@google.com \
--cc=anup@brainfault.org \
--cc=atishp@atishpatra.org \
--cc=chenhuacai@kernel.org \
--cc=coltonlewis@google.com \
--cc=dmatlack@google.com \
--cc=gshan@redhat.com \
--cc=james.morse@arm.com \
--cc=jingzhangos@google.com \
--cc=kvm-riscv@lists.infradead.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=pbonzini@redhat.com \
--cc=rananta@google.com \
--cc=reijiw@google.com \
--cc=shahuang@redhat.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=yuzenghui@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox