* [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation
@ 2023-01-19 17:35 ` David Matlack
0 siblings, 0 replies; 64+ messages in thread
From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw)
To: kvm-riscv
This series introduces a common API for performing range-based TLB
invalidation. This is then used to supplant
kvm_arch_flush_remote_tlbs_memslot() and pave the way for two other
patch series:
1. https://lore.kernel.org/kvm/20230109215347.3119271-1-rananta at google.com/
Adds ARM support for range-based TLB invalidation and needs a
mechanism to invoke it from common code. This series provides such a
mechanism via kvm_arch_flush_remote_tlbs_range().
2. https://lore.kernel.org/kvm/20221208193857.4090582-1-dmatlack at google.com/
Refactors the TDP MMU into common code, which requires an API for
range-based TLB invaliation.
This series is based on patches 29-33 from (2.), but I made some further
cleanups after looking at it a second time.
Tested on x86_64 and ARM64 using KVM selftests.
Cc: Raghavendra Rao Ananta <rananta@google.com>
David Matlack (7):
KVM: Rename kvm_arch_flush_remote_tlb() to
kvm_arch_flush_remote_tlbs()
KVM: arm64: Use kvm_arch_flush_remote_tlbs()
KVM: x86/mmu: Collapse kvm_flush_remote_tlbs_with_{range,address}()
together
KVM: x86/mmu: Rename kvm_flush_remote_tlbs_with_address()
KVM: x86/MMU: Use gfn_t in kvm_flush_remote_tlbs_range()
KVM: Allow range-based TLB invalidation from common code
KVM: Move kvm_arch_flush_remote_tlbs_memslot() to common code
arch/arm64/include/asm/kvm_host.h | 3 ++
arch/arm64/kvm/Kconfig | 1 -
arch/arm64/kvm/arm.c | 6 ---
arch/arm64/kvm/mmu.c | 6 +--
arch/mips/include/asm/kvm_host.h | 4 +-
arch/mips/kvm/mips.c | 12 ++----
arch/riscv/kvm/mmu.c | 6 ---
arch/x86/include/asm/kvm_host.h | 7 +++-
arch/x86/kvm/mmu/mmu.c | 68 ++++++++++---------------------
arch/x86/kvm/mmu/mmu_internal.h | 2 -
arch/x86/kvm/mmu/paging_tmpl.h | 4 +-
arch/x86/kvm/mmu/tdp_mmu.c | 7 ++--
arch/x86/kvm/x86.c | 2 +-
include/linux/kvm_host.h | 20 ++++++---
virt/kvm/kvm_main.c | 35 +++++++++++++---
15 files changed, 87 insertions(+), 96 deletions(-)
base-commit: de60733246ff4545a0483140c1f21426b8d7cb7f
prerequisite-patch-id: 42a76ce7cec240776c21f674e99e893a3a6bee58
prerequisite-patch-id: c5ef6bbef252706b7e65b76dc9bd92cf320828f5
prerequisite-patch-id: c6e662cb6c369a47a027c25d3ccc7138a19b17f5
prerequisite-patch-id: 15a58bec64bf1537e6c9e2f52179fac652d441f7
prerequisite-patch-id: d5b6fea4724f4f2c3408b95d7ce5acdd4b528b10
--
2.39.0.246.g2a6d74b583-goog
^ permalink raw reply [flat|nested] 64+ messages in thread* [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta This series introduces a common API for performing range-based TLB invalidation. This is then used to supplant kvm_arch_flush_remote_tlbs_memslot() and pave the way for two other patch series: 1. https://lore.kernel.org/kvm/20230109215347.3119271-1-rananta@google.com/ Adds ARM support for range-based TLB invalidation and needs a mechanism to invoke it from common code. This series provides such a mechanism via kvm_arch_flush_remote_tlbs_range(). 2. https://lore.kernel.org/kvm/20221208193857.4090582-1-dmatlack@google.com/ Refactors the TDP MMU into common code, which requires an API for range-based TLB invaliation. This series is based on patches 29-33 from (2.), but I made some further cleanups after looking at it a second time. Tested on x86_64 and ARM64 using KVM selftests. Cc: Raghavendra Rao Ananta <rananta@google.com> David Matlack (7): KVM: Rename kvm_arch_flush_remote_tlb() to kvm_arch_flush_remote_tlbs() KVM: arm64: Use kvm_arch_flush_remote_tlbs() KVM: x86/mmu: Collapse kvm_flush_remote_tlbs_with_{range,address}() together KVM: x86/mmu: Rename kvm_flush_remote_tlbs_with_address() KVM: x86/MMU: Use gfn_t in kvm_flush_remote_tlbs_range() KVM: Allow range-based TLB invalidation from common code KVM: Move kvm_arch_flush_remote_tlbs_memslot() to common code arch/arm64/include/asm/kvm_host.h | 3 ++ arch/arm64/kvm/Kconfig | 1 - arch/arm64/kvm/arm.c | 6 --- arch/arm64/kvm/mmu.c | 6 +-- arch/mips/include/asm/kvm_host.h | 4 +- arch/mips/kvm/mips.c | 12 ++---- arch/riscv/kvm/mmu.c | 6 --- arch/x86/include/asm/kvm_host.h | 7 +++- arch/x86/kvm/mmu/mmu.c | 68 ++++++++++--------------------- arch/x86/kvm/mmu/mmu_internal.h | 2 - arch/x86/kvm/mmu/paging_tmpl.h | 4 +- arch/x86/kvm/mmu/tdp_mmu.c | 7 ++-- arch/x86/kvm/x86.c | 2 +- include/linux/kvm_host.h | 20 ++++++--- virt/kvm/kvm_main.c | 35 +++++++++++++--- 15 files changed, 87 insertions(+), 96 deletions(-) base-commit: de60733246ff4545a0483140c1f21426b8d7cb7f prerequisite-patch-id: 42a76ce7cec240776c21f674e99e893a3a6bee58 prerequisite-patch-id: c5ef6bbef252706b7e65b76dc9bd92cf320828f5 prerequisite-patch-id: c6e662cb6c369a47a027c25d3ccc7138a19b17f5 prerequisite-patch-id: 15a58bec64bf1537e6c9e2f52179fac652d441f7 prerequisite-patch-id: d5b6fea4724f4f2c3408b95d7ce5acdd4b528b10 -- 2.39.0.246.g2a6d74b583-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta This series introduces a common API for performing range-based TLB invalidation. This is then used to supplant kvm_arch_flush_remote_tlbs_memslot() and pave the way for two other patch series: 1. https://lore.kernel.org/kvm/20230109215347.3119271-1-rananta@google.com/ Adds ARM support for range-based TLB invalidation and needs a mechanism to invoke it from common code. This series provides such a mechanism via kvm_arch_flush_remote_tlbs_range(). 2. https://lore.kernel.org/kvm/20221208193857.4090582-1-dmatlack@google.com/ Refactors the TDP MMU into common code, which requires an API for range-based TLB invaliation. This series is based on patches 29-33 from (2.), but I made some further cleanups after looking at it a second time. Tested on x86_64 and ARM64 using KVM selftests. Cc: Raghavendra Rao Ananta <rananta@google.com> David Matlack (7): KVM: Rename kvm_arch_flush_remote_tlb() to kvm_arch_flush_remote_tlbs() KVM: arm64: Use kvm_arch_flush_remote_tlbs() KVM: x86/mmu: Collapse kvm_flush_remote_tlbs_with_{range,address}() together KVM: x86/mmu: Rename kvm_flush_remote_tlbs_with_address() KVM: x86/MMU: Use gfn_t in kvm_flush_remote_tlbs_range() KVM: Allow range-based TLB invalidation from common code KVM: Move kvm_arch_flush_remote_tlbs_memslot() to common code arch/arm64/include/asm/kvm_host.h | 3 ++ arch/arm64/kvm/Kconfig | 1 - arch/arm64/kvm/arm.c | 6 --- arch/arm64/kvm/mmu.c | 6 +-- arch/mips/include/asm/kvm_host.h | 4 +- arch/mips/kvm/mips.c | 12 ++---- arch/riscv/kvm/mmu.c | 6 --- arch/x86/include/asm/kvm_host.h | 7 +++- arch/x86/kvm/mmu/mmu.c | 68 ++++++++++--------------------- arch/x86/kvm/mmu/mmu_internal.h | 2 - arch/x86/kvm/mmu/paging_tmpl.h | 4 +- arch/x86/kvm/mmu/tdp_mmu.c | 7 ++-- arch/x86/kvm/x86.c | 2 +- include/linux/kvm_host.h | 20 ++++++--- virt/kvm/kvm_main.c | 35 +++++++++++++--- 15 files changed, 87 insertions(+), 96 deletions(-) base-commit: de60733246ff4545a0483140c1f21426b8d7cb7f prerequisite-patch-id: 42a76ce7cec240776c21f674e99e893a3a6bee58 prerequisite-patch-id: c5ef6bbef252706b7e65b76dc9bd92cf320828f5 prerequisite-patch-id: c6e662cb6c369a47a027c25d3ccc7138a19b17f5 prerequisite-patch-id: 15a58bec64bf1537e6c9e2f52179fac652d441f7 prerequisite-patch-id: d5b6fea4724f4f2c3408b95d7ce5acdd4b528b10 -- 2.39.0.246.g2a6d74b583-goog _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta This series introduces a common API for performing range-based TLB invalidation. This is then used to supplant kvm_arch_flush_remote_tlbs_memslot() and pave the way for two other patch series: 1. https://lore.kernel.org/kvm/20230109215347.3119271-1-rananta@google.com/ Adds ARM support for range-based TLB invalidation and needs a mechanism to invoke it from common code. This series provides such a mechanism via kvm_arch_flush_remote_tlbs_range(). 2. https://lore.kernel.org/kvm/20221208193857.4090582-1-dmatlack@google.com/ Refactors the TDP MMU into common code, which requires an API for range-based TLB invaliation. This series is based on patches 29-33 from (2.), but I made some further cleanups after looking at it a second time. Tested on x86_64 and ARM64 using KVM selftests. Cc: Raghavendra Rao Ananta <rananta@google.com> David Matlack (7): KVM: Rename kvm_arch_flush_remote_tlb() to kvm_arch_flush_remote_tlbs() KVM: arm64: Use kvm_arch_flush_remote_tlbs() KVM: x86/mmu: Collapse kvm_flush_remote_tlbs_with_{range,address}() together KVM: x86/mmu: Rename kvm_flush_remote_tlbs_with_address() KVM: x86/MMU: Use gfn_t in kvm_flush_remote_tlbs_range() KVM: Allow range-based TLB invalidation from common code KVM: Move kvm_arch_flush_remote_tlbs_memslot() to common code arch/arm64/include/asm/kvm_host.h | 3 ++ arch/arm64/kvm/Kconfig | 1 - arch/arm64/kvm/arm.c | 6 --- arch/arm64/kvm/mmu.c | 6 +-- arch/mips/include/asm/kvm_host.h | 4 +- arch/mips/kvm/mips.c | 12 ++---- arch/riscv/kvm/mmu.c | 6 --- arch/x86/include/asm/kvm_host.h | 7 +++- arch/x86/kvm/mmu/mmu.c | 68 ++++++++++--------------------- arch/x86/kvm/mmu/mmu_internal.h | 2 - arch/x86/kvm/mmu/paging_tmpl.h | 4 +- arch/x86/kvm/mmu/tdp_mmu.c | 7 ++-- arch/x86/kvm/x86.c | 2 +- include/linux/kvm_host.h | 20 ++++++--- virt/kvm/kvm_main.c | 35 +++++++++++++--- 15 files changed, 87 insertions(+), 96 deletions(-) base-commit: de60733246ff4545a0483140c1f21426b8d7cb7f prerequisite-patch-id: 42a76ce7cec240776c21f674e99e893a3a6bee58 prerequisite-patch-id: c5ef6bbef252706b7e65b76dc9bd92cf320828f5 prerequisite-patch-id: c6e662cb6c369a47a027c25d3ccc7138a19b17f5 prerequisite-patch-id: 15a58bec64bf1537e6c9e2f52179fac652d441f7 prerequisite-patch-id: d5b6fea4724f4f2c3408b95d7ce5acdd4b528b10 -- 2.39.0.246.g2a6d74b583-goog ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 1/7] KVM: Rename kvm_arch_flush_remote_tlb() to kvm_arch_flush_remote_tlbs() 2023-01-19 17:35 ` David Matlack (?) (?) @ 2023-01-19 17:35 ` David Matlack -1 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: kvm-riscv Rename kvm_arch_flush_remote_tlb() and the associated macro __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB to kvm_arch_flush_remote_tlbs() and __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS respectively. Making the name plural matches kvm_flush_remote_tlbs() and makes it more clear that this function can affect more than one remote TLB. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/mips/include/asm/kvm_host.h | 4 ++-- arch/mips/kvm/mips.c | 2 +- arch/x86/include/asm/kvm_host.h | 4 ++-- include/linux/kvm_host.h | 4 ++-- virt/kvm/kvm_main.c | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h index 2803c9c21ef9..849eb482ad15 100644 --- a/arch/mips/include/asm/kvm_host.h +++ b/arch/mips/include/asm/kvm_host.h @@ -896,7 +896,7 @@ static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {} static inline void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu) {} static inline void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu) {} -#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB -int kvm_arch_flush_remote_tlb(struct kvm *kvm); +#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS +int kvm_arch_flush_remote_tlbs(struct kvm *kvm); #endif /* __MIPS_KVM_HOST_H__ */ diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c index 36c8991b5d39..2e54e5fd8daa 100644 --- a/arch/mips/kvm/mips.c +++ b/arch/mips/kvm/mips.c @@ -981,7 +981,7 @@ void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot) } -int kvm_arch_flush_remote_tlb(struct kvm *kvm) +int kvm_arch_flush_remote_tlbs(struct kvm *kvm) { kvm_mips_callbacks->prepare_flush_shadow(kvm); return 1; diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 4d2bc08794e4..1bacc3de2432 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1789,8 +1789,8 @@ static inline struct kvm *kvm_arch_alloc_vm(void) #define __KVM_HAVE_ARCH_VM_FREE void kvm_arch_free_vm(struct kvm *kvm); -#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB -static inline int kvm_arch_flush_remote_tlb(struct kvm *kvm) +#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS +static inline int kvm_arch_flush_remote_tlbs(struct kvm *kvm) { if (kvm_x86_ops.tlb_remote_flush && !static_call(kvm_x86_tlb_remote_flush)(kvm)) diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 109b18e2789c..76711afe4d17 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -1477,8 +1477,8 @@ static inline void kvm_arch_free_vm(struct kvm *kvm) } #endif -#ifndef __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB -static inline int kvm_arch_flush_remote_tlb(struct kvm *kvm) +#ifndef __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS +static inline int kvm_arch_flush_remote_tlbs(struct kvm *kvm) { return -ENOTSUPP; } diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index d255964ec331..277507463678 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -363,7 +363,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm) * kvm_make_all_cpus_request() reads vcpu->mode. We reuse that * barrier here. */ - if (!kvm_arch_flush_remote_tlb(kvm) + if (!kvm_arch_flush_remote_tlbs(kvm) || kvm_make_all_cpus_request(kvm, KVM_REQ_TLB_FLUSH)) ++kvm->stat.generic.remote_tlb_flush; } -- 2.39.0.246.g2a6d74b583-goog ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 1/7] KVM: Rename kvm_arch_flush_remote_tlb() to kvm_arch_flush_remote_tlbs() @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Rename kvm_arch_flush_remote_tlb() and the associated macro __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB to kvm_arch_flush_remote_tlbs() and __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS respectively. Making the name plural matches kvm_flush_remote_tlbs() and makes it more clear that this function can affect more than one remote TLB. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/mips/include/asm/kvm_host.h | 4 ++-- arch/mips/kvm/mips.c | 2 +- arch/x86/include/asm/kvm_host.h | 4 ++-- include/linux/kvm_host.h | 4 ++-- virt/kvm/kvm_main.c | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h index 2803c9c21ef9..849eb482ad15 100644 --- a/arch/mips/include/asm/kvm_host.h +++ b/arch/mips/include/asm/kvm_host.h @@ -896,7 +896,7 @@ static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {} static inline void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu) {} static inline void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu) {} -#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB -int kvm_arch_flush_remote_tlb(struct kvm *kvm); +#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS +int kvm_arch_flush_remote_tlbs(struct kvm *kvm); #endif /* __MIPS_KVM_HOST_H__ */ diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c index 36c8991b5d39..2e54e5fd8daa 100644 --- a/arch/mips/kvm/mips.c +++ b/arch/mips/kvm/mips.c @@ -981,7 +981,7 @@ void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot) } -int kvm_arch_flush_remote_tlb(struct kvm *kvm) +int kvm_arch_flush_remote_tlbs(struct kvm *kvm) { kvm_mips_callbacks->prepare_flush_shadow(kvm); return 1; diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 4d2bc08794e4..1bacc3de2432 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1789,8 +1789,8 @@ static inline struct kvm *kvm_arch_alloc_vm(void) #define __KVM_HAVE_ARCH_VM_FREE void kvm_arch_free_vm(struct kvm *kvm); -#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB -static inline int kvm_arch_flush_remote_tlb(struct kvm *kvm) +#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS +static inline int kvm_arch_flush_remote_tlbs(struct kvm *kvm) { if (kvm_x86_ops.tlb_remote_flush && !static_call(kvm_x86_tlb_remote_flush)(kvm)) diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 109b18e2789c..76711afe4d17 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -1477,8 +1477,8 @@ static inline void kvm_arch_free_vm(struct kvm *kvm) } #endif -#ifndef __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB -static inline int kvm_arch_flush_remote_tlb(struct kvm *kvm) +#ifndef __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS +static inline int kvm_arch_flush_remote_tlbs(struct kvm *kvm) { return -ENOTSUPP; } diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index d255964ec331..277507463678 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -363,7 +363,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm) * kvm_make_all_cpus_request() reads vcpu->mode. We reuse that * barrier here. */ - if (!kvm_arch_flush_remote_tlb(kvm) + if (!kvm_arch_flush_remote_tlbs(kvm) || kvm_make_all_cpus_request(kvm, KVM_REQ_TLB_FLUSH)) ++kvm->stat.generic.remote_tlb_flush; } -- 2.39.0.246.g2a6d74b583-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 1/7] KVM: Rename kvm_arch_flush_remote_tlb() to kvm_arch_flush_remote_tlbs() @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Rename kvm_arch_flush_remote_tlb() and the associated macro __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB to kvm_arch_flush_remote_tlbs() and __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS respectively. Making the name plural matches kvm_flush_remote_tlbs() and makes it more clear that this function can affect more than one remote TLB. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/mips/include/asm/kvm_host.h | 4 ++-- arch/mips/kvm/mips.c | 2 +- arch/x86/include/asm/kvm_host.h | 4 ++-- include/linux/kvm_host.h | 4 ++-- virt/kvm/kvm_main.c | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h index 2803c9c21ef9..849eb482ad15 100644 --- a/arch/mips/include/asm/kvm_host.h +++ b/arch/mips/include/asm/kvm_host.h @@ -896,7 +896,7 @@ static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {} static inline void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu) {} static inline void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu) {} -#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB -int kvm_arch_flush_remote_tlb(struct kvm *kvm); +#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS +int kvm_arch_flush_remote_tlbs(struct kvm *kvm); #endif /* __MIPS_KVM_HOST_H__ */ diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c index 36c8991b5d39..2e54e5fd8daa 100644 --- a/arch/mips/kvm/mips.c +++ b/arch/mips/kvm/mips.c @@ -981,7 +981,7 @@ void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot) } -int kvm_arch_flush_remote_tlb(struct kvm *kvm) +int kvm_arch_flush_remote_tlbs(struct kvm *kvm) { kvm_mips_callbacks->prepare_flush_shadow(kvm); return 1; diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 4d2bc08794e4..1bacc3de2432 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1789,8 +1789,8 @@ static inline struct kvm *kvm_arch_alloc_vm(void) #define __KVM_HAVE_ARCH_VM_FREE void kvm_arch_free_vm(struct kvm *kvm); -#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB -static inline int kvm_arch_flush_remote_tlb(struct kvm *kvm) +#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS +static inline int kvm_arch_flush_remote_tlbs(struct kvm *kvm) { if (kvm_x86_ops.tlb_remote_flush && !static_call(kvm_x86_tlb_remote_flush)(kvm)) diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 109b18e2789c..76711afe4d17 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -1477,8 +1477,8 @@ static inline void kvm_arch_free_vm(struct kvm *kvm) } #endif -#ifndef __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB -static inline int kvm_arch_flush_remote_tlb(struct kvm *kvm) +#ifndef __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS +static inline int kvm_arch_flush_remote_tlbs(struct kvm *kvm) { return -ENOTSUPP; } diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index d255964ec331..277507463678 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -363,7 +363,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm) * kvm_make_all_cpus_request() reads vcpu->mode. We reuse that * barrier here. */ - if (!kvm_arch_flush_remote_tlb(kvm) + if (!kvm_arch_flush_remote_tlbs(kvm) || kvm_make_all_cpus_request(kvm, KVM_REQ_TLB_FLUSH)) ++kvm->stat.generic.remote_tlb_flush; } -- 2.39.0.246.g2a6d74b583-goog _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 1/7] KVM: Rename kvm_arch_flush_remote_tlb() to kvm_arch_flush_remote_tlbs() @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Rename kvm_arch_flush_remote_tlb() and the associated macro __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB to kvm_arch_flush_remote_tlbs() and __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS respectively. Making the name plural matches kvm_flush_remote_tlbs() and makes it more clear that this function can affect more than one remote TLB. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/mips/include/asm/kvm_host.h | 4 ++-- arch/mips/kvm/mips.c | 2 +- arch/x86/include/asm/kvm_host.h | 4 ++-- include/linux/kvm_host.h | 4 ++-- virt/kvm/kvm_main.c | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h index 2803c9c21ef9..849eb482ad15 100644 --- a/arch/mips/include/asm/kvm_host.h +++ b/arch/mips/include/asm/kvm_host.h @@ -896,7 +896,7 @@ static inline void kvm_arch_sched_in(struct kvm_vcpu *vcpu, int cpu) {} static inline void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu) {} static inline void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu) {} -#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB -int kvm_arch_flush_remote_tlb(struct kvm *kvm); +#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS +int kvm_arch_flush_remote_tlbs(struct kvm *kvm); #endif /* __MIPS_KVM_HOST_H__ */ diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c index 36c8991b5d39..2e54e5fd8daa 100644 --- a/arch/mips/kvm/mips.c +++ b/arch/mips/kvm/mips.c @@ -981,7 +981,7 @@ void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot) } -int kvm_arch_flush_remote_tlb(struct kvm *kvm) +int kvm_arch_flush_remote_tlbs(struct kvm *kvm) { kvm_mips_callbacks->prepare_flush_shadow(kvm); return 1; diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 4d2bc08794e4..1bacc3de2432 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1789,8 +1789,8 @@ static inline struct kvm *kvm_arch_alloc_vm(void) #define __KVM_HAVE_ARCH_VM_FREE void kvm_arch_free_vm(struct kvm *kvm); -#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB -static inline int kvm_arch_flush_remote_tlb(struct kvm *kvm) +#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS +static inline int kvm_arch_flush_remote_tlbs(struct kvm *kvm) { if (kvm_x86_ops.tlb_remote_flush && !static_call(kvm_x86_tlb_remote_flush)(kvm)) diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 109b18e2789c..76711afe4d17 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -1477,8 +1477,8 @@ static inline void kvm_arch_free_vm(struct kvm *kvm) } #endif -#ifndef __KVM_HAVE_ARCH_FLUSH_REMOTE_TLB -static inline int kvm_arch_flush_remote_tlb(struct kvm *kvm) +#ifndef __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS +static inline int kvm_arch_flush_remote_tlbs(struct kvm *kvm) { return -ENOTSUPP; } diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index d255964ec331..277507463678 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -363,7 +363,7 @@ void kvm_flush_remote_tlbs(struct kvm *kvm) * kvm_make_all_cpus_request() reads vcpu->mode. We reuse that * barrier here. */ - if (!kvm_arch_flush_remote_tlb(kvm) + if (!kvm_arch_flush_remote_tlbs(kvm) || kvm_make_all_cpus_request(kvm, KVM_REQ_TLB_FLUSH)) ++kvm->stat.generic.remote_tlb_flush; } -- 2.39.0.246.g2a6d74b583-goog ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 2/7] KVM: arm64: Use kvm_arch_flush_remote_tlbs() 2023-01-19 17:35 ` David Matlack (?) (?) @ 2023-01-19 17:35 ` David Matlack -1 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: kvm-riscv Use kvm_arch_flush_remote_tlbs() instead of CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL. The two mechanisms solve the same problem, allowing architecture-specific code to provide a non-IPI implementation of remote TLB flushing. Dropping CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL allows KVM to standardize all architectures on kvm_arch_flush_remote_tlbs() instead of maintaining two mechanisms. Opt to standardize on kvm_arch_flush_remote_tlbs() since it avoids duplicating the generic TLB stats across architectures that implement their own remote TLB flush. This adds an extra function call to the ARM64 kvm_flush_remote_tlbs() path, but (I assume) that is a small cost in comparison to flushing remote TLBs. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/arm64/include/asm/kvm_host.h | 3 +++ arch/arm64/kvm/Kconfig | 1 - arch/arm64/kvm/mmu.c | 6 +++--- virt/kvm/kvm_main.c | 2 -- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index 113e20fdbb56..062800f1dc54 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -998,6 +998,9 @@ int __init kvm_set_ipa_limit(void); #define __KVM_HAVE_ARCH_VM_ALLOC struct kvm *kvm_arch_alloc_vm(void); +#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS +int kvm_arch_flush_remote_tlbs(struct kvm *kvm); + static inline bool kvm_vm_is_protected(struct kvm *kvm) { return false; diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index ca6eadeb7d1a..e9ac57098a0b 100644 --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -25,7 +25,6 @@ menuconfig KVM select MMU_NOTIFIER select PREEMPT_NOTIFIERS select HAVE_KVM_CPU_RELAX_INTERCEPT - select HAVE_KVM_ARCH_TLB_FLUSH_ALL select KVM_MMIO select KVM_GENERIC_DIRTYLOG_READ_PROTECT select KVM_XFER_TO_GUEST_WORK diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index 01352f5838a0..8840f65e0e40 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -80,15 +80,15 @@ static bool memslot_is_logging(struct kvm_memory_slot *memslot) } /** - * kvm_flush_remote_tlbs() - flush all VM TLB entries for v7/8 + * kvm_arch_flush_remote_tlbs() - flush all VM TLB entries for v7/8 * @kvm: pointer to kvm structure. * * Interface to HYP function to flush all VM TLB entries */ -void kvm_flush_remote_tlbs(struct kvm *kvm) +int kvm_arch_flush_remote_tlbs(struct kvm *kvm) { - ++kvm->stat.generic.remote_tlb_flush_requests; kvm_call_hyp(__kvm_tlb_flush_vmid, &kvm->arch.mmu); + return 0; } static bool kvm_is_device_pfn(unsigned long pfn) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 277507463678..fefd3e3c8fe1 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -347,7 +347,6 @@ bool kvm_make_all_cpus_request(struct kvm *kvm, unsigned int req) } EXPORT_SYMBOL_GPL(kvm_make_all_cpus_request); -#ifndef CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL void kvm_flush_remote_tlbs(struct kvm *kvm) { ++kvm->stat.generic.remote_tlb_flush_requests; @@ -368,7 +367,6 @@ void kvm_flush_remote_tlbs(struct kvm *kvm) ++kvm->stat.generic.remote_tlb_flush; } EXPORT_SYMBOL_GPL(kvm_flush_remote_tlbs); -#endif static void kvm_flush_shadow_all(struct kvm *kvm) { -- 2.39.0.246.g2a6d74b583-goog ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 2/7] KVM: arm64: Use kvm_arch_flush_remote_tlbs() @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Use kvm_arch_flush_remote_tlbs() instead of CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL. The two mechanisms solve the same problem, allowing architecture-specific code to provide a non-IPI implementation of remote TLB flushing. Dropping CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL allows KVM to standardize all architectures on kvm_arch_flush_remote_tlbs() instead of maintaining two mechanisms. Opt to standardize on kvm_arch_flush_remote_tlbs() since it avoids duplicating the generic TLB stats across architectures that implement their own remote TLB flush. This adds an extra function call to the ARM64 kvm_flush_remote_tlbs() path, but (I assume) that is a small cost in comparison to flushing remote TLBs. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/arm64/include/asm/kvm_host.h | 3 +++ arch/arm64/kvm/Kconfig | 1 - arch/arm64/kvm/mmu.c | 6 +++--- virt/kvm/kvm_main.c | 2 -- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index 113e20fdbb56..062800f1dc54 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -998,6 +998,9 @@ int __init kvm_set_ipa_limit(void); #define __KVM_HAVE_ARCH_VM_ALLOC struct kvm *kvm_arch_alloc_vm(void); +#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS +int kvm_arch_flush_remote_tlbs(struct kvm *kvm); + static inline bool kvm_vm_is_protected(struct kvm *kvm) { return false; diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index ca6eadeb7d1a..e9ac57098a0b 100644 --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -25,7 +25,6 @@ menuconfig KVM select MMU_NOTIFIER select PREEMPT_NOTIFIERS select HAVE_KVM_CPU_RELAX_INTERCEPT - select HAVE_KVM_ARCH_TLB_FLUSH_ALL select KVM_MMIO select KVM_GENERIC_DIRTYLOG_READ_PROTECT select KVM_XFER_TO_GUEST_WORK diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index 01352f5838a0..8840f65e0e40 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -80,15 +80,15 @@ static bool memslot_is_logging(struct kvm_memory_slot *memslot) } /** - * kvm_flush_remote_tlbs() - flush all VM TLB entries for v7/8 + * kvm_arch_flush_remote_tlbs() - flush all VM TLB entries for v7/8 * @kvm: pointer to kvm structure. * * Interface to HYP function to flush all VM TLB entries */ -void kvm_flush_remote_tlbs(struct kvm *kvm) +int kvm_arch_flush_remote_tlbs(struct kvm *kvm) { - ++kvm->stat.generic.remote_tlb_flush_requests; kvm_call_hyp(__kvm_tlb_flush_vmid, &kvm->arch.mmu); + return 0; } static bool kvm_is_device_pfn(unsigned long pfn) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 277507463678..fefd3e3c8fe1 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -347,7 +347,6 @@ bool kvm_make_all_cpus_request(struct kvm *kvm, unsigned int req) } EXPORT_SYMBOL_GPL(kvm_make_all_cpus_request); -#ifndef CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL void kvm_flush_remote_tlbs(struct kvm *kvm) { ++kvm->stat.generic.remote_tlb_flush_requests; @@ -368,7 +367,6 @@ void kvm_flush_remote_tlbs(struct kvm *kvm) ++kvm->stat.generic.remote_tlb_flush; } EXPORT_SYMBOL_GPL(kvm_flush_remote_tlbs); -#endif static void kvm_flush_shadow_all(struct kvm *kvm) { -- 2.39.0.246.g2a6d74b583-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 2/7] KVM: arm64: Use kvm_arch_flush_remote_tlbs() @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Use kvm_arch_flush_remote_tlbs() instead of CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL. The two mechanisms solve the same problem, allowing architecture-specific code to provide a non-IPI implementation of remote TLB flushing. Dropping CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL allows KVM to standardize all architectures on kvm_arch_flush_remote_tlbs() instead of maintaining two mechanisms. Opt to standardize on kvm_arch_flush_remote_tlbs() since it avoids duplicating the generic TLB stats across architectures that implement their own remote TLB flush. This adds an extra function call to the ARM64 kvm_flush_remote_tlbs() path, but (I assume) that is a small cost in comparison to flushing remote TLBs. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/arm64/include/asm/kvm_host.h | 3 +++ arch/arm64/kvm/Kconfig | 1 - arch/arm64/kvm/mmu.c | 6 +++--- virt/kvm/kvm_main.c | 2 -- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index 113e20fdbb56..062800f1dc54 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -998,6 +998,9 @@ int __init kvm_set_ipa_limit(void); #define __KVM_HAVE_ARCH_VM_ALLOC struct kvm *kvm_arch_alloc_vm(void); +#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS +int kvm_arch_flush_remote_tlbs(struct kvm *kvm); + static inline bool kvm_vm_is_protected(struct kvm *kvm) { return false; diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index ca6eadeb7d1a..e9ac57098a0b 100644 --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -25,7 +25,6 @@ menuconfig KVM select MMU_NOTIFIER select PREEMPT_NOTIFIERS select HAVE_KVM_CPU_RELAX_INTERCEPT - select HAVE_KVM_ARCH_TLB_FLUSH_ALL select KVM_MMIO select KVM_GENERIC_DIRTYLOG_READ_PROTECT select KVM_XFER_TO_GUEST_WORK diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index 01352f5838a0..8840f65e0e40 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -80,15 +80,15 @@ static bool memslot_is_logging(struct kvm_memory_slot *memslot) } /** - * kvm_flush_remote_tlbs() - flush all VM TLB entries for v7/8 + * kvm_arch_flush_remote_tlbs() - flush all VM TLB entries for v7/8 * @kvm: pointer to kvm structure. * * Interface to HYP function to flush all VM TLB entries */ -void kvm_flush_remote_tlbs(struct kvm *kvm) +int kvm_arch_flush_remote_tlbs(struct kvm *kvm) { - ++kvm->stat.generic.remote_tlb_flush_requests; kvm_call_hyp(__kvm_tlb_flush_vmid, &kvm->arch.mmu); + return 0; } static bool kvm_is_device_pfn(unsigned long pfn) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 277507463678..fefd3e3c8fe1 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -347,7 +347,6 @@ bool kvm_make_all_cpus_request(struct kvm *kvm, unsigned int req) } EXPORT_SYMBOL_GPL(kvm_make_all_cpus_request); -#ifndef CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL void kvm_flush_remote_tlbs(struct kvm *kvm) { ++kvm->stat.generic.remote_tlb_flush_requests; @@ -368,7 +367,6 @@ void kvm_flush_remote_tlbs(struct kvm *kvm) ++kvm->stat.generic.remote_tlb_flush; } EXPORT_SYMBOL_GPL(kvm_flush_remote_tlbs); -#endif static void kvm_flush_shadow_all(struct kvm *kvm) { -- 2.39.0.246.g2a6d74b583-goog _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 2/7] KVM: arm64: Use kvm_arch_flush_remote_tlbs() @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Use kvm_arch_flush_remote_tlbs() instead of CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL. The two mechanisms solve the same problem, allowing architecture-specific code to provide a non-IPI implementation of remote TLB flushing. Dropping CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL allows KVM to standardize all architectures on kvm_arch_flush_remote_tlbs() instead of maintaining two mechanisms. Opt to standardize on kvm_arch_flush_remote_tlbs() since it avoids duplicating the generic TLB stats across architectures that implement their own remote TLB flush. This adds an extra function call to the ARM64 kvm_flush_remote_tlbs() path, but (I assume) that is a small cost in comparison to flushing remote TLBs. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/arm64/include/asm/kvm_host.h | 3 +++ arch/arm64/kvm/Kconfig | 1 - arch/arm64/kvm/mmu.c | 6 +++--- virt/kvm/kvm_main.c | 2 -- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index 113e20fdbb56..062800f1dc54 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -998,6 +998,9 @@ int __init kvm_set_ipa_limit(void); #define __KVM_HAVE_ARCH_VM_ALLOC struct kvm *kvm_arch_alloc_vm(void); +#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS +int kvm_arch_flush_remote_tlbs(struct kvm *kvm); + static inline bool kvm_vm_is_protected(struct kvm *kvm) { return false; diff --git a/arch/arm64/kvm/Kconfig b/arch/arm64/kvm/Kconfig index ca6eadeb7d1a..e9ac57098a0b 100644 --- a/arch/arm64/kvm/Kconfig +++ b/arch/arm64/kvm/Kconfig @@ -25,7 +25,6 @@ menuconfig KVM select MMU_NOTIFIER select PREEMPT_NOTIFIERS select HAVE_KVM_CPU_RELAX_INTERCEPT - select HAVE_KVM_ARCH_TLB_FLUSH_ALL select KVM_MMIO select KVM_GENERIC_DIRTYLOG_READ_PROTECT select KVM_XFER_TO_GUEST_WORK diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c index 01352f5838a0..8840f65e0e40 100644 --- a/arch/arm64/kvm/mmu.c +++ b/arch/arm64/kvm/mmu.c @@ -80,15 +80,15 @@ static bool memslot_is_logging(struct kvm_memory_slot *memslot) } /** - * kvm_flush_remote_tlbs() - flush all VM TLB entries for v7/8 + * kvm_arch_flush_remote_tlbs() - flush all VM TLB entries for v7/8 * @kvm: pointer to kvm structure. * * Interface to HYP function to flush all VM TLB entries */ -void kvm_flush_remote_tlbs(struct kvm *kvm) +int kvm_arch_flush_remote_tlbs(struct kvm *kvm) { - ++kvm->stat.generic.remote_tlb_flush_requests; kvm_call_hyp(__kvm_tlb_flush_vmid, &kvm->arch.mmu); + return 0; } static bool kvm_is_device_pfn(unsigned long pfn) diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 277507463678..fefd3e3c8fe1 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -347,7 +347,6 @@ bool kvm_make_all_cpus_request(struct kvm *kvm, unsigned int req) } EXPORT_SYMBOL_GPL(kvm_make_all_cpus_request); -#ifndef CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL void kvm_flush_remote_tlbs(struct kvm *kvm) { ++kvm->stat.generic.remote_tlb_flush_requests; @@ -368,7 +367,6 @@ void kvm_flush_remote_tlbs(struct kvm *kvm) ++kvm->stat.generic.remote_tlb_flush; } EXPORT_SYMBOL_GPL(kvm_flush_remote_tlbs); -#endif static void kvm_flush_shadow_all(struct kvm *kvm) { -- 2.39.0.246.g2a6d74b583-goog ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 2/7] KVM: arm64: Use kvm_arch_flush_remote_tlbs() 2023-01-19 17:35 ` David Matlack (?) (?) @ 2023-01-24 17:17 ` Oliver Upton -1 siblings, 0 replies; 64+ messages in thread From: Oliver Upton @ 2023-01-24 17:17 UTC (permalink / raw) To: kvm-riscv Hi David, On Thu, Jan 19, 2023 at 09:35:54AM -0800, David Matlack wrote: > Use kvm_arch_flush_remote_tlbs() instead of > CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL. The two mechanisms solve the same > problem, allowing architecture-specific code to provide a non-IPI > implementation of remote TLB flushing. > > Dropping CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL allows KVM to standardize > all architectures on kvm_arch_flush_remote_tlbs() instead of maintaining > two mechanisms. > > Opt to standardize on kvm_arch_flush_remote_tlbs() since it avoids > duplicating the generic TLB stats across architectures that implement > their own remote TLB flush. > > This adds an extra function call to the ARM64 kvm_flush_remote_tlbs() > path, but (I assume) that is a small cost in comparison to flushing > remote TLBs. A fair assumption indeed. The real pile up occurs on the DSB subsequent to the TLBI. > No functional change intended. > > Signed-off-by: David Matlack <dmatlack@google.com> > --- > arch/arm64/include/asm/kvm_host.h | 3 +++ > arch/arm64/kvm/Kconfig | 1 - > arch/arm64/kvm/mmu.c | 6 +++--- > virt/kvm/kvm_main.c | 2 -- > 4 files changed, 6 insertions(+), 6 deletions(-) I think you're missing the diff that actually drops the Kconfig opton from virt/kvm/Kconfig. -- Thanks, Oliver ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 2/7] KVM: arm64: Use kvm_arch_flush_remote_tlbs() @ 2023-01-24 17:17 ` Oliver Upton 0 siblings, 0 replies; 64+ messages in thread From: Oliver Upton @ 2023-01-24 17:17 UTC (permalink / raw) To: David Matlack Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta Hi David, On Thu, Jan 19, 2023 at 09:35:54AM -0800, David Matlack wrote: > Use kvm_arch_flush_remote_tlbs() instead of > CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL. The two mechanisms solve the same > problem, allowing architecture-specific code to provide a non-IPI > implementation of remote TLB flushing. > > Dropping CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL allows KVM to standardize > all architectures on kvm_arch_flush_remote_tlbs() instead of maintaining > two mechanisms. > > Opt to standardize on kvm_arch_flush_remote_tlbs() since it avoids > duplicating the generic TLB stats across architectures that implement > their own remote TLB flush. > > This adds an extra function call to the ARM64 kvm_flush_remote_tlbs() > path, but (I assume) that is a small cost in comparison to flushing > remote TLBs. A fair assumption indeed. The real pile up occurs on the DSB subsequent to the TLBI. > No functional change intended. > > Signed-off-by: David Matlack <dmatlack@google.com> > --- > arch/arm64/include/asm/kvm_host.h | 3 +++ > arch/arm64/kvm/Kconfig | 1 - > arch/arm64/kvm/mmu.c | 6 +++--- > virt/kvm/kvm_main.c | 2 -- > 4 files changed, 6 insertions(+), 6 deletions(-) I think you're missing the diff that actually drops the Kconfig opton from virt/kvm/Kconfig. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 2/7] KVM: arm64: Use kvm_arch_flush_remote_tlbs() @ 2023-01-24 17:17 ` Oliver Upton 0 siblings, 0 replies; 64+ messages in thread From: Oliver Upton @ 2023-01-24 17:17 UTC (permalink / raw) To: David Matlack Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta Hi David, On Thu, Jan 19, 2023 at 09:35:54AM -0800, David Matlack wrote: > Use kvm_arch_flush_remote_tlbs() instead of > CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL. The two mechanisms solve the same > problem, allowing architecture-specific code to provide a non-IPI > implementation of remote TLB flushing. > > Dropping CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL allows KVM to standardize > all architectures on kvm_arch_flush_remote_tlbs() instead of maintaining > two mechanisms. > > Opt to standardize on kvm_arch_flush_remote_tlbs() since it avoids > duplicating the generic TLB stats across architectures that implement > their own remote TLB flush. > > This adds an extra function call to the ARM64 kvm_flush_remote_tlbs() > path, but (I assume) that is a small cost in comparison to flushing > remote TLBs. A fair assumption indeed. The real pile up occurs on the DSB subsequent to the TLBI. > No functional change intended. > > Signed-off-by: David Matlack <dmatlack@google.com> > --- > arch/arm64/include/asm/kvm_host.h | 3 +++ > arch/arm64/kvm/Kconfig | 1 - > arch/arm64/kvm/mmu.c | 6 +++--- > virt/kvm/kvm_main.c | 2 -- > 4 files changed, 6 insertions(+), 6 deletions(-) I think you're missing the diff that actually drops the Kconfig opton from virt/kvm/Kconfig. -- Thanks, Oliver _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 2/7] KVM: arm64: Use kvm_arch_flush_remote_tlbs() @ 2023-01-24 17:17 ` Oliver Upton 0 siblings, 0 replies; 64+ messages in thread From: Oliver Upton @ 2023-01-24 17:17 UTC (permalink / raw) To: David Matlack Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta Hi David, On Thu, Jan 19, 2023 at 09:35:54AM -0800, David Matlack wrote: > Use kvm_arch_flush_remote_tlbs() instead of > CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL. The two mechanisms solve the same > problem, allowing architecture-specific code to provide a non-IPI > implementation of remote TLB flushing. > > Dropping CONFIG_HAVE_KVM_ARCH_TLB_FLUSH_ALL allows KVM to standardize > all architectures on kvm_arch_flush_remote_tlbs() instead of maintaining > two mechanisms. > > Opt to standardize on kvm_arch_flush_remote_tlbs() since it avoids > duplicating the generic TLB stats across architectures that implement > their own remote TLB flush. > > This adds an extra function call to the ARM64 kvm_flush_remote_tlbs() > path, but (I assume) that is a small cost in comparison to flushing > remote TLBs. A fair assumption indeed. The real pile up occurs on the DSB subsequent to the TLBI. > No functional change intended. > > Signed-off-by: David Matlack <dmatlack@google.com> > --- > arch/arm64/include/asm/kvm_host.h | 3 +++ > arch/arm64/kvm/Kconfig | 1 - > arch/arm64/kvm/mmu.c | 6 +++--- > virt/kvm/kvm_main.c | 2 -- > 4 files changed, 6 insertions(+), 6 deletions(-) I think you're missing the diff that actually drops the Kconfig opton from virt/kvm/Kconfig. -- Thanks, Oliver ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 2/7] KVM: arm64: Use kvm_arch_flush_remote_tlbs() 2023-01-24 17:17 ` Oliver Upton (?) (?) @ 2023-01-24 17:28 ` David Matlack -1 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-24 17:28 UTC (permalink / raw) To: kvm-riscv On Tue, Jan 24, 2023 at 9:17 AM Oliver Upton <oliver.upton@linux.dev> wrote: > On Thu, Jan 19, 2023 at 09:35:54AM -0800, David Matlack wrote: > > > > arch/arm64/include/asm/kvm_host.h | 3 +++ > > arch/arm64/kvm/Kconfig | 1 - > > arch/arm64/kvm/mmu.c | 6 +++--- > > virt/kvm/kvm_main.c | 2 -- > > 4 files changed, 6 insertions(+), 6 deletions(-) > > I think you're missing the diff that actually drops the Kconfig opton > from virt/kvm/Kconfig. Indeed I am, thanks for catching that! ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 2/7] KVM: arm64: Use kvm_arch_flush_remote_tlbs() @ 2023-01-24 17:28 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-24 17:28 UTC (permalink / raw) To: Oliver Upton Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Tue, Jan 24, 2023 at 9:17 AM Oliver Upton <oliver.upton@linux.dev> wrote: > On Thu, Jan 19, 2023 at 09:35:54AM -0800, David Matlack wrote: > > > > arch/arm64/include/asm/kvm_host.h | 3 +++ > > arch/arm64/kvm/Kconfig | 1 - > > arch/arm64/kvm/mmu.c | 6 +++--- > > virt/kvm/kvm_main.c | 2 -- > > 4 files changed, 6 insertions(+), 6 deletions(-) > > I think you're missing the diff that actually drops the Kconfig opton > from virt/kvm/Kconfig. Indeed I am, thanks for catching that! _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 2/7] KVM: arm64: Use kvm_arch_flush_remote_tlbs() @ 2023-01-24 17:28 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-24 17:28 UTC (permalink / raw) To: Oliver Upton Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Tue, Jan 24, 2023 at 9:17 AM Oliver Upton <oliver.upton@linux.dev> wrote: > On Thu, Jan 19, 2023 at 09:35:54AM -0800, David Matlack wrote: > > > > arch/arm64/include/asm/kvm_host.h | 3 +++ > > arch/arm64/kvm/Kconfig | 1 - > > arch/arm64/kvm/mmu.c | 6 +++--- > > virt/kvm/kvm_main.c | 2 -- > > 4 files changed, 6 insertions(+), 6 deletions(-) > > I think you're missing the diff that actually drops the Kconfig opton > from virt/kvm/Kconfig. Indeed I am, thanks for catching that! _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 2/7] KVM: arm64: Use kvm_arch_flush_remote_tlbs() @ 2023-01-24 17:28 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-24 17:28 UTC (permalink / raw) To: Oliver Upton Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Tue, Jan 24, 2023 at 9:17 AM Oliver Upton <oliver.upton@linux.dev> wrote: > On Thu, Jan 19, 2023 at 09:35:54AM -0800, David Matlack wrote: > > > > arch/arm64/include/asm/kvm_host.h | 3 +++ > > arch/arm64/kvm/Kconfig | 1 - > > arch/arm64/kvm/mmu.c | 6 +++--- > > virt/kvm/kvm_main.c | 2 -- > > 4 files changed, 6 insertions(+), 6 deletions(-) > > I think you're missing the diff that actually drops the Kconfig opton > from virt/kvm/Kconfig. Indeed I am, thanks for catching that! ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 3/7] KVM: x86/mmu: Collapse kvm_flush_remote_tlbs_with_{range,address}() together 2023-01-19 17:35 ` David Matlack (?) (?) @ 2023-01-19 17:35 ` David Matlack -1 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: kvm-riscv Collapse kvm_flush_remote_tlbs_with_range() and kvm_flush_remote_tlbs_with_address() into a single function. This eliminates some lines of code and a useless NULL check on the range struct. Opportunistically switch from ENOTSUPP to EOPNOTSUPP to make checkpatch happy. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/x86/kvm/mmu/mmu.c | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index aeb240b339f5..7740ca52dab4 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -246,27 +246,20 @@ static inline bool kvm_available_flush_tlb_with_range(void) return kvm_x86_ops.tlb_remote_flush_with_range; } -static void kvm_flush_remote_tlbs_with_range(struct kvm *kvm, - struct kvm_tlb_range *range) -{ - int ret = -ENOTSUPP; - - if (range && kvm_x86_ops.tlb_remote_flush_with_range) - ret = static_call(kvm_x86_tlb_remote_flush_with_range)(kvm, range); - - if (ret) - kvm_flush_remote_tlbs(kvm); -} - void kvm_flush_remote_tlbs_with_address(struct kvm *kvm, u64 start_gfn, u64 pages) { struct kvm_tlb_range range; + int ret = -EOPNOTSUPP; range.start_gfn = start_gfn; range.pages = pages; - kvm_flush_remote_tlbs_with_range(kvm, &range); + if (kvm_x86_ops.tlb_remote_flush_with_range) + ret = static_call(kvm_x86_tlb_remote_flush_with_range)(kvm, &range); + + if (ret) + kvm_flush_remote_tlbs(kvm); } static void mark_mmio_spte(struct kvm_vcpu *vcpu, u64 *sptep, u64 gfn, -- 2.39.0.246.g2a6d74b583-goog ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 3/7] KVM: x86/mmu: Collapse kvm_flush_remote_tlbs_with_{range,address}() together @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Collapse kvm_flush_remote_tlbs_with_range() and kvm_flush_remote_tlbs_with_address() into a single function. This eliminates some lines of code and a useless NULL check on the range struct. Opportunistically switch from ENOTSUPP to EOPNOTSUPP to make checkpatch happy. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/x86/kvm/mmu/mmu.c | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index aeb240b339f5..7740ca52dab4 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -246,27 +246,20 @@ static inline bool kvm_available_flush_tlb_with_range(void) return kvm_x86_ops.tlb_remote_flush_with_range; } -static void kvm_flush_remote_tlbs_with_range(struct kvm *kvm, - struct kvm_tlb_range *range) -{ - int ret = -ENOTSUPP; - - if (range && kvm_x86_ops.tlb_remote_flush_with_range) - ret = static_call(kvm_x86_tlb_remote_flush_with_range)(kvm, range); - - if (ret) - kvm_flush_remote_tlbs(kvm); -} - void kvm_flush_remote_tlbs_with_address(struct kvm *kvm, u64 start_gfn, u64 pages) { struct kvm_tlb_range range; + int ret = -EOPNOTSUPP; range.start_gfn = start_gfn; range.pages = pages; - kvm_flush_remote_tlbs_with_range(kvm, &range); + if (kvm_x86_ops.tlb_remote_flush_with_range) + ret = static_call(kvm_x86_tlb_remote_flush_with_range)(kvm, &range); + + if (ret) + kvm_flush_remote_tlbs(kvm); } static void mark_mmio_spte(struct kvm_vcpu *vcpu, u64 *sptep, u64 gfn, -- 2.39.0.246.g2a6d74b583-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 3/7] KVM: x86/mmu: Collapse kvm_flush_remote_tlbs_with_{range,address}() together @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Collapse kvm_flush_remote_tlbs_with_range() and kvm_flush_remote_tlbs_with_address() into a single function. This eliminates some lines of code and a useless NULL check on the range struct. Opportunistically switch from ENOTSUPP to EOPNOTSUPP to make checkpatch happy. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/x86/kvm/mmu/mmu.c | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index aeb240b339f5..7740ca52dab4 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -246,27 +246,20 @@ static inline bool kvm_available_flush_tlb_with_range(void) return kvm_x86_ops.tlb_remote_flush_with_range; } -static void kvm_flush_remote_tlbs_with_range(struct kvm *kvm, - struct kvm_tlb_range *range) -{ - int ret = -ENOTSUPP; - - if (range && kvm_x86_ops.tlb_remote_flush_with_range) - ret = static_call(kvm_x86_tlb_remote_flush_with_range)(kvm, range); - - if (ret) - kvm_flush_remote_tlbs(kvm); -} - void kvm_flush_remote_tlbs_with_address(struct kvm *kvm, u64 start_gfn, u64 pages) { struct kvm_tlb_range range; + int ret = -EOPNOTSUPP; range.start_gfn = start_gfn; range.pages = pages; - kvm_flush_remote_tlbs_with_range(kvm, &range); + if (kvm_x86_ops.tlb_remote_flush_with_range) + ret = static_call(kvm_x86_tlb_remote_flush_with_range)(kvm, &range); + + if (ret) + kvm_flush_remote_tlbs(kvm); } static void mark_mmio_spte(struct kvm_vcpu *vcpu, u64 *sptep, u64 gfn, -- 2.39.0.246.g2a6d74b583-goog _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 3/7] KVM: x86/mmu: Collapse kvm_flush_remote_tlbs_with_{range,address}() together @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Collapse kvm_flush_remote_tlbs_with_range() and kvm_flush_remote_tlbs_with_address() into a single function. This eliminates some lines of code and a useless NULL check on the range struct. Opportunistically switch from ENOTSUPP to EOPNOTSUPP to make checkpatch happy. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/x86/kvm/mmu/mmu.c | 19 ++++++------------- 1 file changed, 6 insertions(+), 13 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index aeb240b339f5..7740ca52dab4 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -246,27 +246,20 @@ static inline bool kvm_available_flush_tlb_with_range(void) return kvm_x86_ops.tlb_remote_flush_with_range; } -static void kvm_flush_remote_tlbs_with_range(struct kvm *kvm, - struct kvm_tlb_range *range) -{ - int ret = -ENOTSUPP; - - if (range && kvm_x86_ops.tlb_remote_flush_with_range) - ret = static_call(kvm_x86_tlb_remote_flush_with_range)(kvm, range); - - if (ret) - kvm_flush_remote_tlbs(kvm); -} - void kvm_flush_remote_tlbs_with_address(struct kvm *kvm, u64 start_gfn, u64 pages) { struct kvm_tlb_range range; + int ret = -EOPNOTSUPP; range.start_gfn = start_gfn; range.pages = pages; - kvm_flush_remote_tlbs_with_range(kvm, &range); + if (kvm_x86_ops.tlb_remote_flush_with_range) + ret = static_call(kvm_x86_tlb_remote_flush_with_range)(kvm, &range); + + if (ret) + kvm_flush_remote_tlbs(kvm); } static void mark_mmio_spte(struct kvm_vcpu *vcpu, u64 *sptep, u64 gfn, -- 2.39.0.246.g2a6d74b583-goog ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 4/7] KVM: x86/mmu: Rename kvm_flush_remote_tlbs_with_address() 2023-01-19 17:35 ` David Matlack (?) (?) @ 2023-01-19 17:35 ` David Matlack -1 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: kvm-riscv Rename kvm_flush_remote_tlbs_with_address() to kvm_flush_remote_tlbs_range(). This name is shorter, which reduces the number of callsites that need to be broken up across multiple lines, and more readable since it conveys a range of memory is being flushed rather than a single address. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/x86/kvm/mmu/mmu.c | 36 +++++++++++++++------------------ arch/x86/kvm/mmu/mmu_internal.h | 3 +-- arch/x86/kvm/mmu/paging_tmpl.h | 4 ++-- arch/x86/kvm/mmu/tdp_mmu.c | 7 +++---- 4 files changed, 22 insertions(+), 28 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 7740ca52dab4..36ce3110b7da 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -246,8 +246,7 @@ static inline bool kvm_available_flush_tlb_with_range(void) return kvm_x86_ops.tlb_remote_flush_with_range; } -void kvm_flush_remote_tlbs_with_address(struct kvm *kvm, - u64 start_gfn, u64 pages) +void kvm_flush_remote_tlbs_range(struct kvm *kvm, u64 start_gfn, u64 pages) { struct kvm_tlb_range range; int ret = -EOPNOTSUPP; @@ -806,7 +805,7 @@ static void account_shadowed(struct kvm *kvm, struct kvm_mmu_page *sp) kvm_mmu_gfn_disallow_lpage(slot, gfn); if (kvm_mmu_slot_gfn_write_protect(kvm, slot, gfn, PG_LEVEL_4K)) - kvm_flush_remote_tlbs_with_address(kvm, gfn, 1); + kvm_flush_remote_tlbs_range(kvm, gfn, 1); } void track_possible_nx_huge_page(struct kvm *kvm, struct kvm_mmu_page *sp) @@ -1180,8 +1179,8 @@ static void drop_large_spte(struct kvm *kvm, u64 *sptep, bool flush) drop_spte(kvm, sptep); if (flush) - kvm_flush_remote_tlbs_with_address(kvm, sp->gfn, - KVM_PAGES_PER_HPAGE(sp->role.level)); + kvm_flush_remote_tlbs_range(kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(sp->role.level)); } /* @@ -1462,7 +1461,7 @@ static bool kvm_set_pte_rmap(struct kvm *kvm, struct kvm_rmap_head *rmap_head, } if (need_flush && kvm_available_flush_tlb_with_range()) { - kvm_flush_remote_tlbs_with_address(kvm, gfn, 1); + kvm_flush_remote_tlbs_range(kvm, gfn, 1); return false; } @@ -1632,8 +1631,8 @@ static void __rmap_add(struct kvm *kvm, kvm->stat.max_mmu_rmap_size = rmap_count; if (rmap_count > RMAP_RECYCLE_THRESHOLD) { kvm_zap_all_rmap_sptes(kvm, rmap_head); - kvm_flush_remote_tlbs_with_address( - kvm, sp->gfn, KVM_PAGES_PER_HPAGE(sp->role.level)); + kvm_flush_remote_tlbs_range(kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(sp->role.level)); } } @@ -2398,7 +2397,7 @@ static void validate_direct_spte(struct kvm_vcpu *vcpu, u64 *sptep, return; drop_parent_pte(child, sptep); - kvm_flush_remote_tlbs_with_address(vcpu->kvm, child->gfn, 1); + kvm_flush_remote_tlbs_range(vcpu->kvm, child->gfn, 1); } } @@ -2882,8 +2881,8 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, struct kvm_memory_slot *slot, } if (flush) - kvm_flush_remote_tlbs_with_address(vcpu->kvm, gfn, - KVM_PAGES_PER_HPAGE(level)); + kvm_flush_remote_tlbs_range(vcpu->kvm, gfn, + KVM_PAGES_PER_HPAGE(level)); pgprintk("%s: setting spte %llx\n", __func__, *sptep); @@ -5814,9 +5813,8 @@ slot_handle_level_range(struct kvm *kvm, const struct kvm_memory_slot *memslot, if (need_resched() || rwlock_needbreak(&kvm->mmu_lock)) { if (flush && flush_on_yield) { - kvm_flush_remote_tlbs_with_address(kvm, - start_gfn, - iterator.gfn - start_gfn + 1); + kvm_flush_remote_tlbs_range(kvm, start_gfn, + iterator.gfn - start_gfn + 1); flush = false; } cond_resched_rwlock_write(&kvm->mmu_lock); @@ -6171,8 +6169,7 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t gfn_start, gfn_t gfn_end) } if (flush) - kvm_flush_remote_tlbs_with_address(kvm, gfn_start, - gfn_end - gfn_start); + kvm_flush_remote_tlbs_range(kvm, gfn_start, gfn_end - gfn_start); kvm_mmu_invalidate_end(kvm, 0, -1ul); @@ -6511,8 +6508,8 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm, kvm_zap_one_rmap_spte(kvm, rmap_head, sptep); if (kvm_available_flush_tlb_with_range()) - kvm_flush_remote_tlbs_with_address(kvm, sp->gfn, - KVM_PAGES_PER_HPAGE(sp->role.level)); + kvm_flush_remote_tlbs_range(kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(sp->role.level)); else need_tlb_flush = 1; @@ -6562,8 +6559,7 @@ void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, * is observed by any other operation on the same memslot. */ lockdep_assert_held(&kvm->slots_lock); - kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn, - memslot->npages); + kvm_flush_remote_tlbs_range(kvm, memslot->base_gfn, memslot->npages); } void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm, diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h index ac00bfbf32f6..e606a6d5e040 100644 --- a/arch/x86/kvm/mmu/mmu_internal.h +++ b/arch/x86/kvm/mmu/mmu_internal.h @@ -164,8 +164,7 @@ void kvm_mmu_gfn_allow_lpage(const struct kvm_memory_slot *slot, gfn_t gfn); bool kvm_mmu_slot_gfn_write_protect(struct kvm *kvm, struct kvm_memory_slot *slot, u64 gfn, int min_level); -void kvm_flush_remote_tlbs_with_address(struct kvm *kvm, - u64 start_gfn, u64 pages); +void kvm_flush_remote_tlbs_range(struct kvm *kvm, u64 start_gfn, u64 pages); unsigned int pte_list_count(struct kvm_rmap_head *rmap_head); extern int nx_huge_pages; diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h index e5662dbd519c..fdad03f131c8 100644 --- a/arch/x86/kvm/mmu/paging_tmpl.h +++ b/arch/x86/kvm/mmu/paging_tmpl.h @@ -929,8 +929,8 @@ static void FNAME(invlpg)(struct kvm_vcpu *vcpu, gva_t gva, hpa_t root_hpa) mmu_page_zap_pte(vcpu->kvm, sp, sptep, NULL); if (is_shadow_present_pte(old_spte)) - kvm_flush_remote_tlbs_with_address(vcpu->kvm, - sp->gfn, KVM_PAGES_PER_HPAGE(sp->role.level)); + kvm_flush_remote_tlbs_range(vcpu->kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(sp->role.level)); if (!rmap_can_add(vcpu)) break; diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c index bba33aea0fb0..7c21d15c58d8 100644 --- a/arch/x86/kvm/mmu/tdp_mmu.c +++ b/arch/x86/kvm/mmu/tdp_mmu.c @@ -680,8 +680,7 @@ static inline int tdp_mmu_zap_spte_atomic(struct kvm *kvm, if (ret) return ret; - kvm_flush_remote_tlbs_with_address(kvm, iter->gfn, - KVM_PAGES_PER_HPAGE(iter->level)); + kvm_flush_remote_tlbs_range(kvm, iter->gfn, KVM_PAGES_PER_HPAGE(iter->level)); /* * No other thread can overwrite the removed SPTE as they must either @@ -1080,8 +1079,8 @@ static int tdp_mmu_map_handle_target_level(struct kvm_vcpu *vcpu, return RET_PF_RETRY; else if (is_shadow_present_pte(iter->old_spte) && !is_last_spte(iter->old_spte, iter->level)) - kvm_flush_remote_tlbs_with_address(vcpu->kvm, sp->gfn, - KVM_PAGES_PER_HPAGE(iter->level + 1)); + kvm_flush_remote_tlbs_range(vcpu->kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(iter->level + 1)); /* * If the page fault was caused by a write but the page is write -- 2.39.0.246.g2a6d74b583-goog ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 4/7] KVM: x86/mmu: Rename kvm_flush_remote_tlbs_with_address() @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Rename kvm_flush_remote_tlbs_with_address() to kvm_flush_remote_tlbs_range(). This name is shorter, which reduces the number of callsites that need to be broken up across multiple lines, and more readable since it conveys a range of memory is being flushed rather than a single address. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/x86/kvm/mmu/mmu.c | 36 +++++++++++++++------------------ arch/x86/kvm/mmu/mmu_internal.h | 3 +-- arch/x86/kvm/mmu/paging_tmpl.h | 4 ++-- arch/x86/kvm/mmu/tdp_mmu.c | 7 +++---- 4 files changed, 22 insertions(+), 28 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 7740ca52dab4..36ce3110b7da 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -246,8 +246,7 @@ static inline bool kvm_available_flush_tlb_with_range(void) return kvm_x86_ops.tlb_remote_flush_with_range; } -void kvm_flush_remote_tlbs_with_address(struct kvm *kvm, - u64 start_gfn, u64 pages) +void kvm_flush_remote_tlbs_range(struct kvm *kvm, u64 start_gfn, u64 pages) { struct kvm_tlb_range range; int ret = -EOPNOTSUPP; @@ -806,7 +805,7 @@ static void account_shadowed(struct kvm *kvm, struct kvm_mmu_page *sp) kvm_mmu_gfn_disallow_lpage(slot, gfn); if (kvm_mmu_slot_gfn_write_protect(kvm, slot, gfn, PG_LEVEL_4K)) - kvm_flush_remote_tlbs_with_address(kvm, gfn, 1); + kvm_flush_remote_tlbs_range(kvm, gfn, 1); } void track_possible_nx_huge_page(struct kvm *kvm, struct kvm_mmu_page *sp) @@ -1180,8 +1179,8 @@ static void drop_large_spte(struct kvm *kvm, u64 *sptep, bool flush) drop_spte(kvm, sptep); if (flush) - kvm_flush_remote_tlbs_with_address(kvm, sp->gfn, - KVM_PAGES_PER_HPAGE(sp->role.level)); + kvm_flush_remote_tlbs_range(kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(sp->role.level)); } /* @@ -1462,7 +1461,7 @@ static bool kvm_set_pte_rmap(struct kvm *kvm, struct kvm_rmap_head *rmap_head, } if (need_flush && kvm_available_flush_tlb_with_range()) { - kvm_flush_remote_tlbs_with_address(kvm, gfn, 1); + kvm_flush_remote_tlbs_range(kvm, gfn, 1); return false; } @@ -1632,8 +1631,8 @@ static void __rmap_add(struct kvm *kvm, kvm->stat.max_mmu_rmap_size = rmap_count; if (rmap_count > RMAP_RECYCLE_THRESHOLD) { kvm_zap_all_rmap_sptes(kvm, rmap_head); - kvm_flush_remote_tlbs_with_address( - kvm, sp->gfn, KVM_PAGES_PER_HPAGE(sp->role.level)); + kvm_flush_remote_tlbs_range(kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(sp->role.level)); } } @@ -2398,7 +2397,7 @@ static void validate_direct_spte(struct kvm_vcpu *vcpu, u64 *sptep, return; drop_parent_pte(child, sptep); - kvm_flush_remote_tlbs_with_address(vcpu->kvm, child->gfn, 1); + kvm_flush_remote_tlbs_range(vcpu->kvm, child->gfn, 1); } } @@ -2882,8 +2881,8 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, struct kvm_memory_slot *slot, } if (flush) - kvm_flush_remote_tlbs_with_address(vcpu->kvm, gfn, - KVM_PAGES_PER_HPAGE(level)); + kvm_flush_remote_tlbs_range(vcpu->kvm, gfn, + KVM_PAGES_PER_HPAGE(level)); pgprintk("%s: setting spte %llx\n", __func__, *sptep); @@ -5814,9 +5813,8 @@ slot_handle_level_range(struct kvm *kvm, const struct kvm_memory_slot *memslot, if (need_resched() || rwlock_needbreak(&kvm->mmu_lock)) { if (flush && flush_on_yield) { - kvm_flush_remote_tlbs_with_address(kvm, - start_gfn, - iterator.gfn - start_gfn + 1); + kvm_flush_remote_tlbs_range(kvm, start_gfn, + iterator.gfn - start_gfn + 1); flush = false; } cond_resched_rwlock_write(&kvm->mmu_lock); @@ -6171,8 +6169,7 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t gfn_start, gfn_t gfn_end) } if (flush) - kvm_flush_remote_tlbs_with_address(kvm, gfn_start, - gfn_end - gfn_start); + kvm_flush_remote_tlbs_range(kvm, gfn_start, gfn_end - gfn_start); kvm_mmu_invalidate_end(kvm, 0, -1ul); @@ -6511,8 +6508,8 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm, kvm_zap_one_rmap_spte(kvm, rmap_head, sptep); if (kvm_available_flush_tlb_with_range()) - kvm_flush_remote_tlbs_with_address(kvm, sp->gfn, - KVM_PAGES_PER_HPAGE(sp->role.level)); + kvm_flush_remote_tlbs_range(kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(sp->role.level)); else need_tlb_flush = 1; @@ -6562,8 +6559,7 @@ void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, * is observed by any other operation on the same memslot. */ lockdep_assert_held(&kvm->slots_lock); - kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn, - memslot->npages); + kvm_flush_remote_tlbs_range(kvm, memslot->base_gfn, memslot->npages); } void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm, diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h index ac00bfbf32f6..e606a6d5e040 100644 --- a/arch/x86/kvm/mmu/mmu_internal.h +++ b/arch/x86/kvm/mmu/mmu_internal.h @@ -164,8 +164,7 @@ void kvm_mmu_gfn_allow_lpage(const struct kvm_memory_slot *slot, gfn_t gfn); bool kvm_mmu_slot_gfn_write_protect(struct kvm *kvm, struct kvm_memory_slot *slot, u64 gfn, int min_level); -void kvm_flush_remote_tlbs_with_address(struct kvm *kvm, - u64 start_gfn, u64 pages); +void kvm_flush_remote_tlbs_range(struct kvm *kvm, u64 start_gfn, u64 pages); unsigned int pte_list_count(struct kvm_rmap_head *rmap_head); extern int nx_huge_pages; diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h index e5662dbd519c..fdad03f131c8 100644 --- a/arch/x86/kvm/mmu/paging_tmpl.h +++ b/arch/x86/kvm/mmu/paging_tmpl.h @@ -929,8 +929,8 @@ static void FNAME(invlpg)(struct kvm_vcpu *vcpu, gva_t gva, hpa_t root_hpa) mmu_page_zap_pte(vcpu->kvm, sp, sptep, NULL); if (is_shadow_present_pte(old_spte)) - kvm_flush_remote_tlbs_with_address(vcpu->kvm, - sp->gfn, KVM_PAGES_PER_HPAGE(sp->role.level)); + kvm_flush_remote_tlbs_range(vcpu->kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(sp->role.level)); if (!rmap_can_add(vcpu)) break; diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c index bba33aea0fb0..7c21d15c58d8 100644 --- a/arch/x86/kvm/mmu/tdp_mmu.c +++ b/arch/x86/kvm/mmu/tdp_mmu.c @@ -680,8 +680,7 @@ static inline int tdp_mmu_zap_spte_atomic(struct kvm *kvm, if (ret) return ret; - kvm_flush_remote_tlbs_with_address(kvm, iter->gfn, - KVM_PAGES_PER_HPAGE(iter->level)); + kvm_flush_remote_tlbs_range(kvm, iter->gfn, KVM_PAGES_PER_HPAGE(iter->level)); /* * No other thread can overwrite the removed SPTE as they must either @@ -1080,8 +1079,8 @@ static int tdp_mmu_map_handle_target_level(struct kvm_vcpu *vcpu, return RET_PF_RETRY; else if (is_shadow_present_pte(iter->old_spte) && !is_last_spte(iter->old_spte, iter->level)) - kvm_flush_remote_tlbs_with_address(vcpu->kvm, sp->gfn, - KVM_PAGES_PER_HPAGE(iter->level + 1)); + kvm_flush_remote_tlbs_range(vcpu->kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(iter->level + 1)); /* * If the page fault was caused by a write but the page is write -- 2.39.0.246.g2a6d74b583-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 4/7] KVM: x86/mmu: Rename kvm_flush_remote_tlbs_with_address() @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Rename kvm_flush_remote_tlbs_with_address() to kvm_flush_remote_tlbs_range(). This name is shorter, which reduces the number of callsites that need to be broken up across multiple lines, and more readable since it conveys a range of memory is being flushed rather than a single address. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/x86/kvm/mmu/mmu.c | 36 +++++++++++++++------------------ arch/x86/kvm/mmu/mmu_internal.h | 3 +-- arch/x86/kvm/mmu/paging_tmpl.h | 4 ++-- arch/x86/kvm/mmu/tdp_mmu.c | 7 +++---- 4 files changed, 22 insertions(+), 28 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 7740ca52dab4..36ce3110b7da 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -246,8 +246,7 @@ static inline bool kvm_available_flush_tlb_with_range(void) return kvm_x86_ops.tlb_remote_flush_with_range; } -void kvm_flush_remote_tlbs_with_address(struct kvm *kvm, - u64 start_gfn, u64 pages) +void kvm_flush_remote_tlbs_range(struct kvm *kvm, u64 start_gfn, u64 pages) { struct kvm_tlb_range range; int ret = -EOPNOTSUPP; @@ -806,7 +805,7 @@ static void account_shadowed(struct kvm *kvm, struct kvm_mmu_page *sp) kvm_mmu_gfn_disallow_lpage(slot, gfn); if (kvm_mmu_slot_gfn_write_protect(kvm, slot, gfn, PG_LEVEL_4K)) - kvm_flush_remote_tlbs_with_address(kvm, gfn, 1); + kvm_flush_remote_tlbs_range(kvm, gfn, 1); } void track_possible_nx_huge_page(struct kvm *kvm, struct kvm_mmu_page *sp) @@ -1180,8 +1179,8 @@ static void drop_large_spte(struct kvm *kvm, u64 *sptep, bool flush) drop_spte(kvm, sptep); if (flush) - kvm_flush_remote_tlbs_with_address(kvm, sp->gfn, - KVM_PAGES_PER_HPAGE(sp->role.level)); + kvm_flush_remote_tlbs_range(kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(sp->role.level)); } /* @@ -1462,7 +1461,7 @@ static bool kvm_set_pte_rmap(struct kvm *kvm, struct kvm_rmap_head *rmap_head, } if (need_flush && kvm_available_flush_tlb_with_range()) { - kvm_flush_remote_tlbs_with_address(kvm, gfn, 1); + kvm_flush_remote_tlbs_range(kvm, gfn, 1); return false; } @@ -1632,8 +1631,8 @@ static void __rmap_add(struct kvm *kvm, kvm->stat.max_mmu_rmap_size = rmap_count; if (rmap_count > RMAP_RECYCLE_THRESHOLD) { kvm_zap_all_rmap_sptes(kvm, rmap_head); - kvm_flush_remote_tlbs_with_address( - kvm, sp->gfn, KVM_PAGES_PER_HPAGE(sp->role.level)); + kvm_flush_remote_tlbs_range(kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(sp->role.level)); } } @@ -2398,7 +2397,7 @@ static void validate_direct_spte(struct kvm_vcpu *vcpu, u64 *sptep, return; drop_parent_pte(child, sptep); - kvm_flush_remote_tlbs_with_address(vcpu->kvm, child->gfn, 1); + kvm_flush_remote_tlbs_range(vcpu->kvm, child->gfn, 1); } } @@ -2882,8 +2881,8 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, struct kvm_memory_slot *slot, } if (flush) - kvm_flush_remote_tlbs_with_address(vcpu->kvm, gfn, - KVM_PAGES_PER_HPAGE(level)); + kvm_flush_remote_tlbs_range(vcpu->kvm, gfn, + KVM_PAGES_PER_HPAGE(level)); pgprintk("%s: setting spte %llx\n", __func__, *sptep); @@ -5814,9 +5813,8 @@ slot_handle_level_range(struct kvm *kvm, const struct kvm_memory_slot *memslot, if (need_resched() || rwlock_needbreak(&kvm->mmu_lock)) { if (flush && flush_on_yield) { - kvm_flush_remote_tlbs_with_address(kvm, - start_gfn, - iterator.gfn - start_gfn + 1); + kvm_flush_remote_tlbs_range(kvm, start_gfn, + iterator.gfn - start_gfn + 1); flush = false; } cond_resched_rwlock_write(&kvm->mmu_lock); @@ -6171,8 +6169,7 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t gfn_start, gfn_t gfn_end) } if (flush) - kvm_flush_remote_tlbs_with_address(kvm, gfn_start, - gfn_end - gfn_start); + kvm_flush_remote_tlbs_range(kvm, gfn_start, gfn_end - gfn_start); kvm_mmu_invalidate_end(kvm, 0, -1ul); @@ -6511,8 +6508,8 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm, kvm_zap_one_rmap_spte(kvm, rmap_head, sptep); if (kvm_available_flush_tlb_with_range()) - kvm_flush_remote_tlbs_with_address(kvm, sp->gfn, - KVM_PAGES_PER_HPAGE(sp->role.level)); + kvm_flush_remote_tlbs_range(kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(sp->role.level)); else need_tlb_flush = 1; @@ -6562,8 +6559,7 @@ void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, * is observed by any other operation on the same memslot. */ lockdep_assert_held(&kvm->slots_lock); - kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn, - memslot->npages); + kvm_flush_remote_tlbs_range(kvm, memslot->base_gfn, memslot->npages); } void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm, diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h index ac00bfbf32f6..e606a6d5e040 100644 --- a/arch/x86/kvm/mmu/mmu_internal.h +++ b/arch/x86/kvm/mmu/mmu_internal.h @@ -164,8 +164,7 @@ void kvm_mmu_gfn_allow_lpage(const struct kvm_memory_slot *slot, gfn_t gfn); bool kvm_mmu_slot_gfn_write_protect(struct kvm *kvm, struct kvm_memory_slot *slot, u64 gfn, int min_level); -void kvm_flush_remote_tlbs_with_address(struct kvm *kvm, - u64 start_gfn, u64 pages); +void kvm_flush_remote_tlbs_range(struct kvm *kvm, u64 start_gfn, u64 pages); unsigned int pte_list_count(struct kvm_rmap_head *rmap_head); extern int nx_huge_pages; diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h index e5662dbd519c..fdad03f131c8 100644 --- a/arch/x86/kvm/mmu/paging_tmpl.h +++ b/arch/x86/kvm/mmu/paging_tmpl.h @@ -929,8 +929,8 @@ static void FNAME(invlpg)(struct kvm_vcpu *vcpu, gva_t gva, hpa_t root_hpa) mmu_page_zap_pte(vcpu->kvm, sp, sptep, NULL); if (is_shadow_present_pte(old_spte)) - kvm_flush_remote_tlbs_with_address(vcpu->kvm, - sp->gfn, KVM_PAGES_PER_HPAGE(sp->role.level)); + kvm_flush_remote_tlbs_range(vcpu->kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(sp->role.level)); if (!rmap_can_add(vcpu)) break; diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c index bba33aea0fb0..7c21d15c58d8 100644 --- a/arch/x86/kvm/mmu/tdp_mmu.c +++ b/arch/x86/kvm/mmu/tdp_mmu.c @@ -680,8 +680,7 @@ static inline int tdp_mmu_zap_spte_atomic(struct kvm *kvm, if (ret) return ret; - kvm_flush_remote_tlbs_with_address(kvm, iter->gfn, - KVM_PAGES_PER_HPAGE(iter->level)); + kvm_flush_remote_tlbs_range(kvm, iter->gfn, KVM_PAGES_PER_HPAGE(iter->level)); /* * No other thread can overwrite the removed SPTE as they must either @@ -1080,8 +1079,8 @@ static int tdp_mmu_map_handle_target_level(struct kvm_vcpu *vcpu, return RET_PF_RETRY; else if (is_shadow_present_pte(iter->old_spte) && !is_last_spte(iter->old_spte, iter->level)) - kvm_flush_remote_tlbs_with_address(vcpu->kvm, sp->gfn, - KVM_PAGES_PER_HPAGE(iter->level + 1)); + kvm_flush_remote_tlbs_range(vcpu->kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(iter->level + 1)); /* * If the page fault was caused by a write but the page is write -- 2.39.0.246.g2a6d74b583-goog _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 4/7] KVM: x86/mmu: Rename kvm_flush_remote_tlbs_with_address() @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Rename kvm_flush_remote_tlbs_with_address() to kvm_flush_remote_tlbs_range(). This name is shorter, which reduces the number of callsites that need to be broken up across multiple lines, and more readable since it conveys a range of memory is being flushed rather than a single address. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/x86/kvm/mmu/mmu.c | 36 +++++++++++++++------------------ arch/x86/kvm/mmu/mmu_internal.h | 3 +-- arch/x86/kvm/mmu/paging_tmpl.h | 4 ++-- arch/x86/kvm/mmu/tdp_mmu.c | 7 +++---- 4 files changed, 22 insertions(+), 28 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 7740ca52dab4..36ce3110b7da 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -246,8 +246,7 @@ static inline bool kvm_available_flush_tlb_with_range(void) return kvm_x86_ops.tlb_remote_flush_with_range; } -void kvm_flush_remote_tlbs_with_address(struct kvm *kvm, - u64 start_gfn, u64 pages) +void kvm_flush_remote_tlbs_range(struct kvm *kvm, u64 start_gfn, u64 pages) { struct kvm_tlb_range range; int ret = -EOPNOTSUPP; @@ -806,7 +805,7 @@ static void account_shadowed(struct kvm *kvm, struct kvm_mmu_page *sp) kvm_mmu_gfn_disallow_lpage(slot, gfn); if (kvm_mmu_slot_gfn_write_protect(kvm, slot, gfn, PG_LEVEL_4K)) - kvm_flush_remote_tlbs_with_address(kvm, gfn, 1); + kvm_flush_remote_tlbs_range(kvm, gfn, 1); } void track_possible_nx_huge_page(struct kvm *kvm, struct kvm_mmu_page *sp) @@ -1180,8 +1179,8 @@ static void drop_large_spte(struct kvm *kvm, u64 *sptep, bool flush) drop_spte(kvm, sptep); if (flush) - kvm_flush_remote_tlbs_with_address(kvm, sp->gfn, - KVM_PAGES_PER_HPAGE(sp->role.level)); + kvm_flush_remote_tlbs_range(kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(sp->role.level)); } /* @@ -1462,7 +1461,7 @@ static bool kvm_set_pte_rmap(struct kvm *kvm, struct kvm_rmap_head *rmap_head, } if (need_flush && kvm_available_flush_tlb_with_range()) { - kvm_flush_remote_tlbs_with_address(kvm, gfn, 1); + kvm_flush_remote_tlbs_range(kvm, gfn, 1); return false; } @@ -1632,8 +1631,8 @@ static void __rmap_add(struct kvm *kvm, kvm->stat.max_mmu_rmap_size = rmap_count; if (rmap_count > RMAP_RECYCLE_THRESHOLD) { kvm_zap_all_rmap_sptes(kvm, rmap_head); - kvm_flush_remote_tlbs_with_address( - kvm, sp->gfn, KVM_PAGES_PER_HPAGE(sp->role.level)); + kvm_flush_remote_tlbs_range(kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(sp->role.level)); } } @@ -2398,7 +2397,7 @@ static void validate_direct_spte(struct kvm_vcpu *vcpu, u64 *sptep, return; drop_parent_pte(child, sptep); - kvm_flush_remote_tlbs_with_address(vcpu->kvm, child->gfn, 1); + kvm_flush_remote_tlbs_range(vcpu->kvm, child->gfn, 1); } } @@ -2882,8 +2881,8 @@ static int mmu_set_spte(struct kvm_vcpu *vcpu, struct kvm_memory_slot *slot, } if (flush) - kvm_flush_remote_tlbs_with_address(vcpu->kvm, gfn, - KVM_PAGES_PER_HPAGE(level)); + kvm_flush_remote_tlbs_range(vcpu->kvm, gfn, + KVM_PAGES_PER_HPAGE(level)); pgprintk("%s: setting spte %llx\n", __func__, *sptep); @@ -5814,9 +5813,8 @@ slot_handle_level_range(struct kvm *kvm, const struct kvm_memory_slot *memslot, if (need_resched() || rwlock_needbreak(&kvm->mmu_lock)) { if (flush && flush_on_yield) { - kvm_flush_remote_tlbs_with_address(kvm, - start_gfn, - iterator.gfn - start_gfn + 1); + kvm_flush_remote_tlbs_range(kvm, start_gfn, + iterator.gfn - start_gfn + 1); flush = false; } cond_resched_rwlock_write(&kvm->mmu_lock); @@ -6171,8 +6169,7 @@ void kvm_zap_gfn_range(struct kvm *kvm, gfn_t gfn_start, gfn_t gfn_end) } if (flush) - kvm_flush_remote_tlbs_with_address(kvm, gfn_start, - gfn_end - gfn_start); + kvm_flush_remote_tlbs_range(kvm, gfn_start, gfn_end - gfn_start); kvm_mmu_invalidate_end(kvm, 0, -1ul); @@ -6511,8 +6508,8 @@ static bool kvm_mmu_zap_collapsible_spte(struct kvm *kvm, kvm_zap_one_rmap_spte(kvm, rmap_head, sptep); if (kvm_available_flush_tlb_with_range()) - kvm_flush_remote_tlbs_with_address(kvm, sp->gfn, - KVM_PAGES_PER_HPAGE(sp->role.level)); + kvm_flush_remote_tlbs_range(kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(sp->role.level)); else need_tlb_flush = 1; @@ -6562,8 +6559,7 @@ void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, * is observed by any other operation on the same memslot. */ lockdep_assert_held(&kvm->slots_lock); - kvm_flush_remote_tlbs_with_address(kvm, memslot->base_gfn, - memslot->npages); + kvm_flush_remote_tlbs_range(kvm, memslot->base_gfn, memslot->npages); } void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm, diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h index ac00bfbf32f6..e606a6d5e040 100644 --- a/arch/x86/kvm/mmu/mmu_internal.h +++ b/arch/x86/kvm/mmu/mmu_internal.h @@ -164,8 +164,7 @@ void kvm_mmu_gfn_allow_lpage(const struct kvm_memory_slot *slot, gfn_t gfn); bool kvm_mmu_slot_gfn_write_protect(struct kvm *kvm, struct kvm_memory_slot *slot, u64 gfn, int min_level); -void kvm_flush_remote_tlbs_with_address(struct kvm *kvm, - u64 start_gfn, u64 pages); +void kvm_flush_remote_tlbs_range(struct kvm *kvm, u64 start_gfn, u64 pages); unsigned int pte_list_count(struct kvm_rmap_head *rmap_head); extern int nx_huge_pages; diff --git a/arch/x86/kvm/mmu/paging_tmpl.h b/arch/x86/kvm/mmu/paging_tmpl.h index e5662dbd519c..fdad03f131c8 100644 --- a/arch/x86/kvm/mmu/paging_tmpl.h +++ b/arch/x86/kvm/mmu/paging_tmpl.h @@ -929,8 +929,8 @@ static void FNAME(invlpg)(struct kvm_vcpu *vcpu, gva_t gva, hpa_t root_hpa) mmu_page_zap_pte(vcpu->kvm, sp, sptep, NULL); if (is_shadow_present_pte(old_spte)) - kvm_flush_remote_tlbs_with_address(vcpu->kvm, - sp->gfn, KVM_PAGES_PER_HPAGE(sp->role.level)); + kvm_flush_remote_tlbs_range(vcpu->kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(sp->role.level)); if (!rmap_can_add(vcpu)) break; diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c index bba33aea0fb0..7c21d15c58d8 100644 --- a/arch/x86/kvm/mmu/tdp_mmu.c +++ b/arch/x86/kvm/mmu/tdp_mmu.c @@ -680,8 +680,7 @@ static inline int tdp_mmu_zap_spte_atomic(struct kvm *kvm, if (ret) return ret; - kvm_flush_remote_tlbs_with_address(kvm, iter->gfn, - KVM_PAGES_PER_HPAGE(iter->level)); + kvm_flush_remote_tlbs_range(kvm, iter->gfn, KVM_PAGES_PER_HPAGE(iter->level)); /* * No other thread can overwrite the removed SPTE as they must either @@ -1080,8 +1079,8 @@ static int tdp_mmu_map_handle_target_level(struct kvm_vcpu *vcpu, return RET_PF_RETRY; else if (is_shadow_present_pte(iter->old_spte) && !is_last_spte(iter->old_spte, iter->level)) - kvm_flush_remote_tlbs_with_address(vcpu->kvm, sp->gfn, - KVM_PAGES_PER_HPAGE(iter->level + 1)); + kvm_flush_remote_tlbs_range(vcpu->kvm, sp->gfn, + KVM_PAGES_PER_HPAGE(iter->level + 1)); /* * If the page fault was caused by a write but the page is write -- 2.39.0.246.g2a6d74b583-goog ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 4/7] KVM: x86/mmu: Rename kvm_flush_remote_tlbs_with_address() 2023-01-19 17:35 ` David Matlack (?) (?) @ 2023-01-19 18:17 ` Sean Christopherson -1 siblings, 0 replies; 64+ messages in thread From: Sean Christopherson @ 2023-01-19 18:17 UTC (permalink / raw) To: kvm-riscv On Thu, Jan 19, 2023, David Matlack wrote: > Rename kvm_flush_remote_tlbs_with_address() to > kvm_flush_remote_tlbs_range(). This name is shorter, which reduces the > number of callsites that need to be broken up across multiple lines, and > more readable since it conveys a range of memory is being flushed rather > than a single address. FYI, this conflicts with Hou's series, which I'm in the process of queueing for v6.3. https://lore.kernel.org/all/cover.1665214747.git.houwenlong.hwl at antgroup.com ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 4/7] KVM: x86/mmu: Rename kvm_flush_remote_tlbs_with_address() @ 2023-01-19 18:17 ` Sean Christopherson 0 siblings, 0 replies; 64+ messages in thread From: Sean Christopherson @ 2023-01-19 18:17 UTC (permalink / raw) To: David Matlack Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Thu, Jan 19, 2023, David Matlack wrote: > Rename kvm_flush_remote_tlbs_with_address() to > kvm_flush_remote_tlbs_range(). This name is shorter, which reduces the > number of callsites that need to be broken up across multiple lines, and > more readable since it conveys a range of memory is being flushed rather > than a single address. FYI, this conflicts with Hou's series, which I'm in the process of queueing for v6.3. https://lore.kernel.org/all/cover.1665214747.git.houwenlong.hwl@antgroup.com _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 4/7] KVM: x86/mmu: Rename kvm_flush_remote_tlbs_with_address() @ 2023-01-19 18:17 ` Sean Christopherson 0 siblings, 0 replies; 64+ messages in thread From: Sean Christopherson @ 2023-01-19 18:17 UTC (permalink / raw) To: David Matlack Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Thu, Jan 19, 2023, David Matlack wrote: > Rename kvm_flush_remote_tlbs_with_address() to > kvm_flush_remote_tlbs_range(). This name is shorter, which reduces the > number of callsites that need to be broken up across multiple lines, and > more readable since it conveys a range of memory is being flushed rather > than a single address. FYI, this conflicts with Hou's series, which I'm in the process of queueing for v6.3. https://lore.kernel.org/all/cover.1665214747.git.houwenlong.hwl@antgroup.com _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 4/7] KVM: x86/mmu: Rename kvm_flush_remote_tlbs_with_address() @ 2023-01-19 18:17 ` Sean Christopherson 0 siblings, 0 replies; 64+ messages in thread From: Sean Christopherson @ 2023-01-19 18:17 UTC (permalink / raw) To: David Matlack Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Thu, Jan 19, 2023, David Matlack wrote: > Rename kvm_flush_remote_tlbs_with_address() to > kvm_flush_remote_tlbs_range(). This name is shorter, which reduces the > number of callsites that need to be broken up across multiple lines, and > more readable since it conveys a range of memory is being flushed rather > than a single address. FYI, this conflicts with Hou's series, which I'm in the process of queueing for v6.3. https://lore.kernel.org/all/cover.1665214747.git.houwenlong.hwl@antgroup.com ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 4/7] KVM: x86/mmu: Rename kvm_flush_remote_tlbs_with_address() 2023-01-19 18:17 ` Sean Christopherson (?) (?) @ 2023-01-19 18:26 ` David Matlack -1 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 18:26 UTC (permalink / raw) To: kvm-riscv On Thu, Jan 19, 2023 at 10:17 AM Sean Christopherson <seanjc@google.com> wrote: > > On Thu, Jan 19, 2023, David Matlack wrote: > > Rename kvm_flush_remote_tlbs_with_address() to > > kvm_flush_remote_tlbs_range(). This name is shorter, which reduces the > > number of callsites that need to be broken up across multiple lines, and > > more readable since it conveys a range of memory is being flushed rather > > than a single address. > > FYI, this conflicts with Hou's series, which I'm in the process of queueing for > v6.3. > > https://lore.kernel.org/all/cover.1665214747.git.houwenlong.hwl at antgroup.com Ack. I can resend on top of Hou's once it's queued. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 4/7] KVM: x86/mmu: Rename kvm_flush_remote_tlbs_with_address() @ 2023-01-19 18:26 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 18:26 UTC (permalink / raw) To: Sean Christopherson Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Thu, Jan 19, 2023 at 10:17 AM Sean Christopherson <seanjc@google.com> wrote: > > On Thu, Jan 19, 2023, David Matlack wrote: > > Rename kvm_flush_remote_tlbs_with_address() to > > kvm_flush_remote_tlbs_range(). This name is shorter, which reduces the > > number of callsites that need to be broken up across multiple lines, and > > more readable since it conveys a range of memory is being flushed rather > > than a single address. > > FYI, this conflicts with Hou's series, which I'm in the process of queueing for > v6.3. > > https://lore.kernel.org/all/cover.1665214747.git.houwenlong.hwl@antgroup.com Ack. I can resend on top of Hou's once it's queued. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 4/7] KVM: x86/mmu: Rename kvm_flush_remote_tlbs_with_address() @ 2023-01-19 18:26 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 18:26 UTC (permalink / raw) To: Sean Christopherson Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Thu, Jan 19, 2023 at 10:17 AM Sean Christopherson <seanjc@google.com> wrote: > > On Thu, Jan 19, 2023, David Matlack wrote: > > Rename kvm_flush_remote_tlbs_with_address() to > > kvm_flush_remote_tlbs_range(). This name is shorter, which reduces the > > number of callsites that need to be broken up across multiple lines, and > > more readable since it conveys a range of memory is being flushed rather > > than a single address. > > FYI, this conflicts with Hou's series, which I'm in the process of queueing for > v6.3. > > https://lore.kernel.org/all/cover.1665214747.git.houwenlong.hwl@antgroup.com Ack. I can resend on top of Hou's once it's queued. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 4/7] KVM: x86/mmu: Rename kvm_flush_remote_tlbs_with_address() @ 2023-01-19 18:26 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 18:26 UTC (permalink / raw) To: Sean Christopherson Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Thu, Jan 19, 2023 at 10:17 AM Sean Christopherson <seanjc@google.com> wrote: > > On Thu, Jan 19, 2023, David Matlack wrote: > > Rename kvm_flush_remote_tlbs_with_address() to > > kvm_flush_remote_tlbs_range(). This name is shorter, which reduces the > > number of callsites that need to be broken up across multiple lines, and > > more readable since it conveys a range of memory is being flushed rather > > than a single address. > > FYI, this conflicts with Hou's series, which I'm in the process of queueing for > v6.3. > > https://lore.kernel.org/all/cover.1665214747.git.houwenlong.hwl@antgroup.com Ack. I can resend on top of Hou's once it's queued. ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 5/7] KVM: x86/MMU: Use gfn_t in kvm_flush_remote_tlbs_range() 2023-01-19 17:35 ` David Matlack (?) (?) @ 2023-01-19 17:35 ` David Matlack -1 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: kvm-riscv Use gfn_t instead of u64 for the start_gfn parameter to kvm_flush_remote_tlbs_range(), since that is the standard type for GFNs throughout KVM. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/x86/kvm/mmu/mmu.c | 2 +- arch/x86/kvm/mmu/mmu_internal.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 36ce3110b7da..1e2c2d711dbb 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -246,7 +246,7 @@ static inline bool kvm_available_flush_tlb_with_range(void) return kvm_x86_ops.tlb_remote_flush_with_range; } -void kvm_flush_remote_tlbs_range(struct kvm *kvm, u64 start_gfn, u64 pages) +void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages) { struct kvm_tlb_range range; int ret = -EOPNOTSUPP; diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h index e606a6d5e040..851982a25502 100644 --- a/arch/x86/kvm/mmu/mmu_internal.h +++ b/arch/x86/kvm/mmu/mmu_internal.h @@ -164,7 +164,7 @@ void kvm_mmu_gfn_allow_lpage(const struct kvm_memory_slot *slot, gfn_t gfn); bool kvm_mmu_slot_gfn_write_protect(struct kvm *kvm, struct kvm_memory_slot *slot, u64 gfn, int min_level); -void kvm_flush_remote_tlbs_range(struct kvm *kvm, u64 start_gfn, u64 pages); +void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages); unsigned int pte_list_count(struct kvm_rmap_head *rmap_head); extern int nx_huge_pages; -- 2.39.0.246.g2a6d74b583-goog ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 5/7] KVM: x86/MMU: Use gfn_t in kvm_flush_remote_tlbs_range() @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Use gfn_t instead of u64 for the start_gfn parameter to kvm_flush_remote_tlbs_range(), since that is the standard type for GFNs throughout KVM. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/x86/kvm/mmu/mmu.c | 2 +- arch/x86/kvm/mmu/mmu_internal.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 36ce3110b7da..1e2c2d711dbb 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -246,7 +246,7 @@ static inline bool kvm_available_flush_tlb_with_range(void) return kvm_x86_ops.tlb_remote_flush_with_range; } -void kvm_flush_remote_tlbs_range(struct kvm *kvm, u64 start_gfn, u64 pages) +void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages) { struct kvm_tlb_range range; int ret = -EOPNOTSUPP; diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h index e606a6d5e040..851982a25502 100644 --- a/arch/x86/kvm/mmu/mmu_internal.h +++ b/arch/x86/kvm/mmu/mmu_internal.h @@ -164,7 +164,7 @@ void kvm_mmu_gfn_allow_lpage(const struct kvm_memory_slot *slot, gfn_t gfn); bool kvm_mmu_slot_gfn_write_protect(struct kvm *kvm, struct kvm_memory_slot *slot, u64 gfn, int min_level); -void kvm_flush_remote_tlbs_range(struct kvm *kvm, u64 start_gfn, u64 pages); +void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages); unsigned int pte_list_count(struct kvm_rmap_head *rmap_head); extern int nx_huge_pages; -- 2.39.0.246.g2a6d74b583-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 5/7] KVM: x86/MMU: Use gfn_t in kvm_flush_remote_tlbs_range() @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Use gfn_t instead of u64 for the start_gfn parameter to kvm_flush_remote_tlbs_range(), since that is the standard type for GFNs throughout KVM. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/x86/kvm/mmu/mmu.c | 2 +- arch/x86/kvm/mmu/mmu_internal.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 36ce3110b7da..1e2c2d711dbb 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -246,7 +246,7 @@ static inline bool kvm_available_flush_tlb_with_range(void) return kvm_x86_ops.tlb_remote_flush_with_range; } -void kvm_flush_remote_tlbs_range(struct kvm *kvm, u64 start_gfn, u64 pages) +void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages) { struct kvm_tlb_range range; int ret = -EOPNOTSUPP; diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h index e606a6d5e040..851982a25502 100644 --- a/arch/x86/kvm/mmu/mmu_internal.h +++ b/arch/x86/kvm/mmu/mmu_internal.h @@ -164,7 +164,7 @@ void kvm_mmu_gfn_allow_lpage(const struct kvm_memory_slot *slot, gfn_t gfn); bool kvm_mmu_slot_gfn_write_protect(struct kvm *kvm, struct kvm_memory_slot *slot, u64 gfn, int min_level); -void kvm_flush_remote_tlbs_range(struct kvm *kvm, u64 start_gfn, u64 pages); +void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages); unsigned int pte_list_count(struct kvm_rmap_head *rmap_head); extern int nx_huge_pages; -- 2.39.0.246.g2a6d74b583-goog _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 5/7] KVM: x86/MMU: Use gfn_t in kvm_flush_remote_tlbs_range() @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Use gfn_t instead of u64 for the start_gfn parameter to kvm_flush_remote_tlbs_range(), since that is the standard type for GFNs throughout KVM. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/x86/kvm/mmu/mmu.c | 2 +- arch/x86/kvm/mmu/mmu_internal.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 36ce3110b7da..1e2c2d711dbb 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -246,7 +246,7 @@ static inline bool kvm_available_flush_tlb_with_range(void) return kvm_x86_ops.tlb_remote_flush_with_range; } -void kvm_flush_remote_tlbs_range(struct kvm *kvm, u64 start_gfn, u64 pages) +void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages) { struct kvm_tlb_range range; int ret = -EOPNOTSUPP; diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h index e606a6d5e040..851982a25502 100644 --- a/arch/x86/kvm/mmu/mmu_internal.h +++ b/arch/x86/kvm/mmu/mmu_internal.h @@ -164,7 +164,7 @@ void kvm_mmu_gfn_allow_lpage(const struct kvm_memory_slot *slot, gfn_t gfn); bool kvm_mmu_slot_gfn_write_protect(struct kvm *kvm, struct kvm_memory_slot *slot, u64 gfn, int min_level); -void kvm_flush_remote_tlbs_range(struct kvm *kvm, u64 start_gfn, u64 pages); +void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages); unsigned int pte_list_count(struct kvm_rmap_head *rmap_head); extern int nx_huge_pages; -- 2.39.0.246.g2a6d74b583-goog ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 6/7] KVM: Allow range-based TLB invalidation from common code 2023-01-19 17:35 ` David Matlack (?) (?) @ 2023-01-19 17:35 ` David Matlack -1 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: kvm-riscv Make kvm_flush_remote_tlbs_range() visible in common code and create a default implementation that just invalidates the whole TLB. This paves the way for several future cleanups: - Introduction of range-based TLBI on ARM. - Eliminating kvm_arch_flush_remote_tlbs_memslot() - Moving the KVM/x86 TDP MMU to common code. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/x86/include/asm/kvm_host.h | 3 +++ arch/x86/kvm/mmu/mmu.c | 5 ++--- arch/x86/kvm/mmu/mmu_internal.h | 1 - include/linux/kvm_host.h | 9 +++++++++ virt/kvm/kvm_main.c | 13 +++++++++++++ 5 files changed, 27 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 1bacc3de2432..420713ac8916 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1799,6 +1799,9 @@ static inline int kvm_arch_flush_remote_tlbs(struct kvm *kvm) return -ENOTSUPP; } +#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS_RANGE +int kvm_arch_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages); + #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 1e2c2d711dbb..491c28d22cbe 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -246,7 +246,7 @@ static inline bool kvm_available_flush_tlb_with_range(void) return kvm_x86_ops.tlb_remote_flush_with_range; } -void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages) +int kvm_arch_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages) { struct kvm_tlb_range range; int ret = -EOPNOTSUPP; @@ -257,8 +257,7 @@ void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages) if (kvm_x86_ops.tlb_remote_flush_with_range) ret = static_call(kvm_x86_tlb_remote_flush_with_range)(kvm, &range); - if (ret) - kvm_flush_remote_tlbs(kvm); + return ret; } static void mark_mmio_spte(struct kvm_vcpu *vcpu, u64 *sptep, u64 gfn, diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h index 851982a25502..d5599f2d3f96 100644 --- a/arch/x86/kvm/mmu/mmu_internal.h +++ b/arch/x86/kvm/mmu/mmu_internal.h @@ -164,7 +164,6 @@ void kvm_mmu_gfn_allow_lpage(const struct kvm_memory_slot *slot, gfn_t gfn); bool kvm_mmu_slot_gfn_write_protect(struct kvm *kvm, struct kvm_memory_slot *slot, u64 gfn, int min_level); -void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages); unsigned int pte_list_count(struct kvm_rmap_head *rmap_head); extern int nx_huge_pages; diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 76711afe4d17..acfb17d9b44d 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -1356,6 +1356,7 @@ int kvm_vcpu_yield_to(struct kvm_vcpu *target); void kvm_vcpu_on_spin(struct kvm_vcpu *vcpu, bool usermode_vcpu_not_eligible); void kvm_flush_remote_tlbs(struct kvm *kvm); +void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t gfn, u64 pages); #ifdef KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE int kvm_mmu_topup_memory_cache(struct kvm_mmu_memory_cache *mc, int min); @@ -1484,6 +1485,14 @@ static inline int kvm_arch_flush_remote_tlbs(struct kvm *kvm) } #endif +#ifndef __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS_RANGE +static inline int kvm_arch_flush_remote_tlbs_range(struct kvm *kvm, + gfn_t gfn, u64 pages) +{ + return -EOPNOTSUPP; +} +#endif + #ifdef __KVM_HAVE_ARCH_NONCOHERENT_DMA void kvm_arch_register_noncoherent_dma(struct kvm *kvm); void kvm_arch_unregister_noncoherent_dma(struct kvm *kvm); diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index fefd3e3c8fe1..c9fc693a39d9 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -368,6 +368,19 @@ void kvm_flush_remote_tlbs(struct kvm *kvm) } EXPORT_SYMBOL_GPL(kvm_flush_remote_tlbs); +void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t gfn, u64 pages) +{ + if (!kvm_arch_flush_remote_tlbs_range(kvm, gfn, pages)) + return; + + /* + * Fall back to a flushing entire TLBs if the architecture range-based + * TLB invalidation is unsupported or can't be performed for whatever + * reason. + */ + kvm_flush_remote_tlbs(kvm); +} + static void kvm_flush_shadow_all(struct kvm *kvm) { kvm_arch_flush_shadow_all(kvm); -- 2.39.0.246.g2a6d74b583-goog ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 6/7] KVM: Allow range-based TLB invalidation from common code @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Make kvm_flush_remote_tlbs_range() visible in common code and create a default implementation that just invalidates the whole TLB. This paves the way for several future cleanups: - Introduction of range-based TLBI on ARM. - Eliminating kvm_arch_flush_remote_tlbs_memslot() - Moving the KVM/x86 TDP MMU to common code. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/x86/include/asm/kvm_host.h | 3 +++ arch/x86/kvm/mmu/mmu.c | 5 ++--- arch/x86/kvm/mmu/mmu_internal.h | 1 - include/linux/kvm_host.h | 9 +++++++++ virt/kvm/kvm_main.c | 13 +++++++++++++ 5 files changed, 27 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 1bacc3de2432..420713ac8916 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1799,6 +1799,9 @@ static inline int kvm_arch_flush_remote_tlbs(struct kvm *kvm) return -ENOTSUPP; } +#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS_RANGE +int kvm_arch_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages); + #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 1e2c2d711dbb..491c28d22cbe 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -246,7 +246,7 @@ static inline bool kvm_available_flush_tlb_with_range(void) return kvm_x86_ops.tlb_remote_flush_with_range; } -void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages) +int kvm_arch_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages) { struct kvm_tlb_range range; int ret = -EOPNOTSUPP; @@ -257,8 +257,7 @@ void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages) if (kvm_x86_ops.tlb_remote_flush_with_range) ret = static_call(kvm_x86_tlb_remote_flush_with_range)(kvm, &range); - if (ret) - kvm_flush_remote_tlbs(kvm); + return ret; } static void mark_mmio_spte(struct kvm_vcpu *vcpu, u64 *sptep, u64 gfn, diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h index 851982a25502..d5599f2d3f96 100644 --- a/arch/x86/kvm/mmu/mmu_internal.h +++ b/arch/x86/kvm/mmu/mmu_internal.h @@ -164,7 +164,6 @@ void kvm_mmu_gfn_allow_lpage(const struct kvm_memory_slot *slot, gfn_t gfn); bool kvm_mmu_slot_gfn_write_protect(struct kvm *kvm, struct kvm_memory_slot *slot, u64 gfn, int min_level); -void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages); unsigned int pte_list_count(struct kvm_rmap_head *rmap_head); extern int nx_huge_pages; diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 76711afe4d17..acfb17d9b44d 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -1356,6 +1356,7 @@ int kvm_vcpu_yield_to(struct kvm_vcpu *target); void kvm_vcpu_on_spin(struct kvm_vcpu *vcpu, bool usermode_vcpu_not_eligible); void kvm_flush_remote_tlbs(struct kvm *kvm); +void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t gfn, u64 pages); #ifdef KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE int kvm_mmu_topup_memory_cache(struct kvm_mmu_memory_cache *mc, int min); @@ -1484,6 +1485,14 @@ static inline int kvm_arch_flush_remote_tlbs(struct kvm *kvm) } #endif +#ifndef __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS_RANGE +static inline int kvm_arch_flush_remote_tlbs_range(struct kvm *kvm, + gfn_t gfn, u64 pages) +{ + return -EOPNOTSUPP; +} +#endif + #ifdef __KVM_HAVE_ARCH_NONCOHERENT_DMA void kvm_arch_register_noncoherent_dma(struct kvm *kvm); void kvm_arch_unregister_noncoherent_dma(struct kvm *kvm); diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index fefd3e3c8fe1..c9fc693a39d9 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -368,6 +368,19 @@ void kvm_flush_remote_tlbs(struct kvm *kvm) } EXPORT_SYMBOL_GPL(kvm_flush_remote_tlbs); +void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t gfn, u64 pages) +{ + if (!kvm_arch_flush_remote_tlbs_range(kvm, gfn, pages)) + return; + + /* + * Fall back to a flushing entire TLBs if the architecture range-based + * TLB invalidation is unsupported or can't be performed for whatever + * reason. + */ + kvm_flush_remote_tlbs(kvm); +} + static void kvm_flush_shadow_all(struct kvm *kvm) { kvm_arch_flush_shadow_all(kvm); -- 2.39.0.246.g2a6d74b583-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 6/7] KVM: Allow range-based TLB invalidation from common code @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Make kvm_flush_remote_tlbs_range() visible in common code and create a default implementation that just invalidates the whole TLB. This paves the way for several future cleanups: - Introduction of range-based TLBI on ARM. - Eliminating kvm_arch_flush_remote_tlbs_memslot() - Moving the KVM/x86 TDP MMU to common code. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/x86/include/asm/kvm_host.h | 3 +++ arch/x86/kvm/mmu/mmu.c | 5 ++--- arch/x86/kvm/mmu/mmu_internal.h | 1 - include/linux/kvm_host.h | 9 +++++++++ virt/kvm/kvm_main.c | 13 +++++++++++++ 5 files changed, 27 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 1bacc3de2432..420713ac8916 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1799,6 +1799,9 @@ static inline int kvm_arch_flush_remote_tlbs(struct kvm *kvm) return -ENOTSUPP; } +#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS_RANGE +int kvm_arch_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages); + #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 1e2c2d711dbb..491c28d22cbe 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -246,7 +246,7 @@ static inline bool kvm_available_flush_tlb_with_range(void) return kvm_x86_ops.tlb_remote_flush_with_range; } -void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages) +int kvm_arch_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages) { struct kvm_tlb_range range; int ret = -EOPNOTSUPP; @@ -257,8 +257,7 @@ void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages) if (kvm_x86_ops.tlb_remote_flush_with_range) ret = static_call(kvm_x86_tlb_remote_flush_with_range)(kvm, &range); - if (ret) - kvm_flush_remote_tlbs(kvm); + return ret; } static void mark_mmio_spte(struct kvm_vcpu *vcpu, u64 *sptep, u64 gfn, diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h index 851982a25502..d5599f2d3f96 100644 --- a/arch/x86/kvm/mmu/mmu_internal.h +++ b/arch/x86/kvm/mmu/mmu_internal.h @@ -164,7 +164,6 @@ void kvm_mmu_gfn_allow_lpage(const struct kvm_memory_slot *slot, gfn_t gfn); bool kvm_mmu_slot_gfn_write_protect(struct kvm *kvm, struct kvm_memory_slot *slot, u64 gfn, int min_level); -void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages); unsigned int pte_list_count(struct kvm_rmap_head *rmap_head); extern int nx_huge_pages; diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 76711afe4d17..acfb17d9b44d 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -1356,6 +1356,7 @@ int kvm_vcpu_yield_to(struct kvm_vcpu *target); void kvm_vcpu_on_spin(struct kvm_vcpu *vcpu, bool usermode_vcpu_not_eligible); void kvm_flush_remote_tlbs(struct kvm *kvm); +void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t gfn, u64 pages); #ifdef KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE int kvm_mmu_topup_memory_cache(struct kvm_mmu_memory_cache *mc, int min); @@ -1484,6 +1485,14 @@ static inline int kvm_arch_flush_remote_tlbs(struct kvm *kvm) } #endif +#ifndef __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS_RANGE +static inline int kvm_arch_flush_remote_tlbs_range(struct kvm *kvm, + gfn_t gfn, u64 pages) +{ + return -EOPNOTSUPP; +} +#endif + #ifdef __KVM_HAVE_ARCH_NONCOHERENT_DMA void kvm_arch_register_noncoherent_dma(struct kvm *kvm); void kvm_arch_unregister_noncoherent_dma(struct kvm *kvm); diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index fefd3e3c8fe1..c9fc693a39d9 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -368,6 +368,19 @@ void kvm_flush_remote_tlbs(struct kvm *kvm) } EXPORT_SYMBOL_GPL(kvm_flush_remote_tlbs); +void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t gfn, u64 pages) +{ + if (!kvm_arch_flush_remote_tlbs_range(kvm, gfn, pages)) + return; + + /* + * Fall back to a flushing entire TLBs if the architecture range-based + * TLB invalidation is unsupported or can't be performed for whatever + * reason. + */ + kvm_flush_remote_tlbs(kvm); +} + static void kvm_flush_shadow_all(struct kvm *kvm) { kvm_arch_flush_shadow_all(kvm); -- 2.39.0.246.g2a6d74b583-goog _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 6/7] KVM: Allow range-based TLB invalidation from common code @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Make kvm_flush_remote_tlbs_range() visible in common code and create a default implementation that just invalidates the whole TLB. This paves the way for several future cleanups: - Introduction of range-based TLBI on ARM. - Eliminating kvm_arch_flush_remote_tlbs_memslot() - Moving the KVM/x86 TDP MMU to common code. No functional change intended. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/x86/include/asm/kvm_host.h | 3 +++ arch/x86/kvm/mmu/mmu.c | 5 ++--- arch/x86/kvm/mmu/mmu_internal.h | 1 - include/linux/kvm_host.h | 9 +++++++++ virt/kvm/kvm_main.c | 13 +++++++++++++ 5 files changed, 27 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 1bacc3de2432..420713ac8916 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -1799,6 +1799,9 @@ static inline int kvm_arch_flush_remote_tlbs(struct kvm *kvm) return -ENOTSUPP; } +#define __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS_RANGE +int kvm_arch_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages); + #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 1e2c2d711dbb..491c28d22cbe 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -246,7 +246,7 @@ static inline bool kvm_available_flush_tlb_with_range(void) return kvm_x86_ops.tlb_remote_flush_with_range; } -void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages) +int kvm_arch_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages) { struct kvm_tlb_range range; int ret = -EOPNOTSUPP; @@ -257,8 +257,7 @@ void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages) if (kvm_x86_ops.tlb_remote_flush_with_range) ret = static_call(kvm_x86_tlb_remote_flush_with_range)(kvm, &range); - if (ret) - kvm_flush_remote_tlbs(kvm); + return ret; } static void mark_mmio_spte(struct kvm_vcpu *vcpu, u64 *sptep, u64 gfn, diff --git a/arch/x86/kvm/mmu/mmu_internal.h b/arch/x86/kvm/mmu/mmu_internal.h index 851982a25502..d5599f2d3f96 100644 --- a/arch/x86/kvm/mmu/mmu_internal.h +++ b/arch/x86/kvm/mmu/mmu_internal.h @@ -164,7 +164,6 @@ void kvm_mmu_gfn_allow_lpage(const struct kvm_memory_slot *slot, gfn_t gfn); bool kvm_mmu_slot_gfn_write_protect(struct kvm *kvm, struct kvm_memory_slot *slot, u64 gfn, int min_level); -void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t start_gfn, u64 pages); unsigned int pte_list_count(struct kvm_rmap_head *rmap_head); extern int nx_huge_pages; diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 76711afe4d17..acfb17d9b44d 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -1356,6 +1356,7 @@ int kvm_vcpu_yield_to(struct kvm_vcpu *target); void kvm_vcpu_on_spin(struct kvm_vcpu *vcpu, bool usermode_vcpu_not_eligible); void kvm_flush_remote_tlbs(struct kvm *kvm); +void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t gfn, u64 pages); #ifdef KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE int kvm_mmu_topup_memory_cache(struct kvm_mmu_memory_cache *mc, int min); @@ -1484,6 +1485,14 @@ static inline int kvm_arch_flush_remote_tlbs(struct kvm *kvm) } #endif +#ifndef __KVM_HAVE_ARCH_FLUSH_REMOTE_TLBS_RANGE +static inline int kvm_arch_flush_remote_tlbs_range(struct kvm *kvm, + gfn_t gfn, u64 pages) +{ + return -EOPNOTSUPP; +} +#endif + #ifdef __KVM_HAVE_ARCH_NONCOHERENT_DMA void kvm_arch_register_noncoherent_dma(struct kvm *kvm); void kvm_arch_unregister_noncoherent_dma(struct kvm *kvm); diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index fefd3e3c8fe1..c9fc693a39d9 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -368,6 +368,19 @@ void kvm_flush_remote_tlbs(struct kvm *kvm) } EXPORT_SYMBOL_GPL(kvm_flush_remote_tlbs); +void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t gfn, u64 pages) +{ + if (!kvm_arch_flush_remote_tlbs_range(kvm, gfn, pages)) + return; + + /* + * Fall back to a flushing entire TLBs if the architecture range-based + * TLB invalidation is unsupported or can't be performed for whatever + * reason. + */ + kvm_flush_remote_tlbs(kvm); +} + static void kvm_flush_shadow_all(struct kvm *kvm) { kvm_arch_flush_shadow_all(kvm); -- 2.39.0.246.g2a6d74b583-goog ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 6/7] KVM: Allow range-based TLB invalidation from common code 2023-01-19 17:35 ` David Matlack (?) (?) @ 2023-01-24 17:17 ` Oliver Upton -1 siblings, 0 replies; 64+ messages in thread From: Oliver Upton @ 2023-01-24 17:17 UTC (permalink / raw) To: kvm-riscv On Thu, Jan 19, 2023 at 09:35:58AM -0800, David Matlack wrote: > Make kvm_flush_remote_tlbs_range() visible in common code and create a > default implementation that just invalidates the whole TLB. > > This paves the way for several future cleanups: > - Introduction of range-based TLBI on ARM. nit: this is definitely a new feature, not a cleanup :) -- Thanks, Oliver ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 6/7] KVM: Allow range-based TLB invalidation from common code @ 2023-01-24 17:17 ` Oliver Upton 0 siblings, 0 replies; 64+ messages in thread From: Oliver Upton @ 2023-01-24 17:17 UTC (permalink / raw) To: David Matlack Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Thu, Jan 19, 2023 at 09:35:58AM -0800, David Matlack wrote: > Make kvm_flush_remote_tlbs_range() visible in common code and create a > default implementation that just invalidates the whole TLB. > > This paves the way for several future cleanups: > - Introduction of range-based TLBI on ARM. nit: this is definitely a new feature, not a cleanup :) -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 6/7] KVM: Allow range-based TLB invalidation from common code @ 2023-01-24 17:17 ` Oliver Upton 0 siblings, 0 replies; 64+ messages in thread From: Oliver Upton @ 2023-01-24 17:17 UTC (permalink / raw) To: David Matlack Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Thu, Jan 19, 2023 at 09:35:58AM -0800, David Matlack wrote: > Make kvm_flush_remote_tlbs_range() visible in common code and create a > default implementation that just invalidates the whole TLB. > > This paves the way for several future cleanups: > - Introduction of range-based TLBI on ARM. nit: this is definitely a new feature, not a cleanup :) -- Thanks, Oliver _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 6/7] KVM: Allow range-based TLB invalidation from common code @ 2023-01-24 17:17 ` Oliver Upton 0 siblings, 0 replies; 64+ messages in thread From: Oliver Upton @ 2023-01-24 17:17 UTC (permalink / raw) To: David Matlack Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Thu, Jan 19, 2023 at 09:35:58AM -0800, David Matlack wrote: > Make kvm_flush_remote_tlbs_range() visible in common code and create a > default implementation that just invalidates the whole TLB. > > This paves the way for several future cleanups: > - Introduction of range-based TLBI on ARM. nit: this is definitely a new feature, not a cleanup :) -- Thanks, Oliver ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 7/7] KVM: Move kvm_arch_flush_remote_tlbs_memslot() to common code 2023-01-19 17:35 ` David Matlack (?) (?) @ 2023-01-19 17:35 ` David Matlack -1 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: kvm-riscv Move kvm_arch_flush_remote_tlbs_memslot() to common code and drop "arch_" from the name. kvm_arch_flush_remote_tlbs_memslot() is just a range-based TLB invalidation where the range is defined by the memslot. Now that kvm_flush_remote_tlbs_range() can be called from common code we can just use that and drop a bunch of duplicate code from the arch directories. Note this adds a lockdep assertion for slots_lock being held when calling kvm_flush_remote_tlbs_memslot(), which was previously only asserted on x86. MIPS has calls to kvm_flush_remote_tlbs_memslot(), but they all hold the slots_lock, so the lockdep assertion continues to hold true. Also drop the CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT ifdef gating kvm_flush_remote_tlbs_memslot(), since it is no longer necessary. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/arm64/kvm/arm.c | 6 ------ arch/mips/kvm/mips.c | 10 ++-------- arch/riscv/kvm/mmu.c | 6 ------ arch/x86/kvm/mmu/mmu.c | 16 +--------------- arch/x86/kvm/x86.c | 2 +- include/linux/kvm_host.h | 7 +++---- virt/kvm/kvm_main.c | 18 ++++++++++++++++-- 7 files changed, 23 insertions(+), 42 deletions(-) diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index 698787ed87e9..54d5d0733b98 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -1420,12 +1420,6 @@ void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot) } -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot) -{ - kvm_flush_remote_tlbs(kvm); -} - static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm, struct kvm_arm_device_addr *dev_addr) { diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c index 2e54e5fd8daa..9f9a7ba7eb2b 100644 --- a/arch/mips/kvm/mips.c +++ b/arch/mips/kvm/mips.c @@ -199,7 +199,7 @@ void kvm_arch_flush_shadow_memslot(struct kvm *kvm, /* Flush slot from GPA */ kvm_mips_flush_gpa_pt(kvm, slot->base_gfn, slot->base_gfn + slot->npages - 1); - kvm_arch_flush_remote_tlbs_memslot(kvm, slot); + kvm_flush_remote_tlbs_memslot(kvm, slot); spin_unlock(&kvm->mmu_lock); } @@ -235,7 +235,7 @@ void kvm_arch_commit_memory_region(struct kvm *kvm, needs_flush = kvm_mips_mkclean_gpa_pt(kvm, new->base_gfn, new->base_gfn + new->npages - 1); if (needs_flush) - kvm_arch_flush_remote_tlbs_memslot(kvm, new); + kvm_flush_remote_tlbs_memslot(kvm, new); spin_unlock(&kvm->mmu_lock); } } @@ -987,12 +987,6 @@ int kvm_arch_flush_remote_tlbs(struct kvm *kvm) return 1; } -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot) -{ - kvm_flush_remote_tlbs(kvm); -} - long kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg) { long r; diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c index 66ef19676fe4..87f30487f59f 100644 --- a/arch/riscv/kvm/mmu.c +++ b/arch/riscv/kvm/mmu.c @@ -406,12 +406,6 @@ void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot) { } -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot) -{ - kvm_flush_remote_tlbs(kvm); -} - void kvm_arch_free_memslot(struct kvm *kvm, struct kvm_memory_slot *free) { } diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 491c28d22cbe..4af85888c98b 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -6528,7 +6528,7 @@ static void kvm_rmap_zap_collapsible_sptes(struct kvm *kvm, */ if (slot_handle_level(kvm, slot, kvm_mmu_zap_collapsible_spte, PG_LEVEL_4K, KVM_MAX_HUGEPAGE_LEVEL - 1, true)) - kvm_arch_flush_remote_tlbs_memslot(kvm, slot); + kvm_flush_remote_tlbs_memslot(kvm, slot); } void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm, @@ -6547,20 +6547,6 @@ void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm, } } -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot) -{ - /* - * All current use cases for flushing the TLBs for a specific memslot - * related to dirty logging, and many do the TLB flush out of mmu_lock. - * The interaction between the various operations on memslot must be - * serialized by slots_locks to ensure the TLB flush from one operation - * is observed by any other operation on the same memslot. - */ - lockdep_assert_held(&kvm->slots_lock); - kvm_flush_remote_tlbs_range(kvm, memslot->base_gfn, memslot->npages); -} - void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm, const struct kvm_memory_slot *memslot) { diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 508074e47bc0..ea7bb4035a60 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -12617,7 +12617,7 @@ static void kvm_mmu_slot_apply_flags(struct kvm *kvm, * See is_writable_pte() for more details (the case involving * access-tracked SPTEs is particularly relevant). */ - kvm_arch_flush_remote_tlbs_memslot(kvm, new); + kvm_flush_remote_tlbs_memslot(kvm, new); } } diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index acfb17d9b44d..12dfecd27c9d 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -1357,6 +1357,8 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *vcpu, bool usermode_vcpu_not_eligible); void kvm_flush_remote_tlbs(struct kvm *kvm); void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t gfn, u64 pages); +void kvm_flush_remote_tlbs_memslot(struct kvm *kvm, + const struct kvm_memory_slot *memslot); #ifdef KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE int kvm_mmu_topup_memory_cache(struct kvm_mmu_memory_cache *mc, int min); @@ -1385,10 +1387,7 @@ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm *kvm, unsigned long mask); void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot); -#ifdef CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot); -#else /* !CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT */ +#ifndef CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm, struct kvm_dirty_log *log); int kvm_get_dirty_log(struct kvm *kvm, struct kvm_dirty_log *log, int *is_dirty, struct kvm_memory_slot **memslot); diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index c9fc693a39d9..9c10cd191a71 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -381,6 +381,20 @@ void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t gfn, u64 pages) kvm_flush_remote_tlbs(kvm); } +void kvm_flush_remote_tlbs_memslot(struct kvm *kvm, + const struct kvm_memory_slot *memslot) +{ + /* + * All current use cases for flushing the TLBs for a specific memslot + * related to dirty logging, and many do the TLB flush out of mmu_lock. + * The interaction between the various operations on memslot must be + * serialized by slots_locks to ensure the TLB flush from one operation + * is observed by any other operation on the same memslot. + */ + lockdep_assert_held(&kvm->slots_lock); + kvm_flush_remote_tlbs_range(kvm, memslot->base_gfn, memslot->npages); +} + static void kvm_flush_shadow_all(struct kvm *kvm) { kvm_arch_flush_shadow_all(kvm); @@ -2188,7 +2202,7 @@ static int kvm_get_dirty_log_protect(struct kvm *kvm, struct kvm_dirty_log *log) } if (flush) - kvm_arch_flush_remote_tlbs_memslot(kvm, memslot); + kvm_flush_remote_tlbs_memslot(kvm, memslot); if (copy_to_user(log->dirty_bitmap, dirty_bitmap_buffer, n)) return -EFAULT; @@ -2305,7 +2319,7 @@ static int kvm_clear_dirty_log_protect(struct kvm *kvm, KVM_MMU_UNLOCK(kvm); if (flush) - kvm_arch_flush_remote_tlbs_memslot(kvm, memslot); + kvm_flush_remote_tlbs_memslot(kvm, memslot); return 0; } -- 2.39.0.246.g2a6d74b583-goog ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 7/7] KVM: Move kvm_arch_flush_remote_tlbs_memslot() to common code @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Move kvm_arch_flush_remote_tlbs_memslot() to common code and drop "arch_" from the name. kvm_arch_flush_remote_tlbs_memslot() is just a range-based TLB invalidation where the range is defined by the memslot. Now that kvm_flush_remote_tlbs_range() can be called from common code we can just use that and drop a bunch of duplicate code from the arch directories. Note this adds a lockdep assertion for slots_lock being held when calling kvm_flush_remote_tlbs_memslot(), which was previously only asserted on x86. MIPS has calls to kvm_flush_remote_tlbs_memslot(), but they all hold the slots_lock, so the lockdep assertion continues to hold true. Also drop the CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT ifdef gating kvm_flush_remote_tlbs_memslot(), since it is no longer necessary. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/arm64/kvm/arm.c | 6 ------ arch/mips/kvm/mips.c | 10 ++-------- arch/riscv/kvm/mmu.c | 6 ------ arch/x86/kvm/mmu/mmu.c | 16 +--------------- arch/x86/kvm/x86.c | 2 +- include/linux/kvm_host.h | 7 +++---- virt/kvm/kvm_main.c | 18 ++++++++++++++++-- 7 files changed, 23 insertions(+), 42 deletions(-) diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index 698787ed87e9..54d5d0733b98 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -1420,12 +1420,6 @@ void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot) } -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot) -{ - kvm_flush_remote_tlbs(kvm); -} - static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm, struct kvm_arm_device_addr *dev_addr) { diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c index 2e54e5fd8daa..9f9a7ba7eb2b 100644 --- a/arch/mips/kvm/mips.c +++ b/arch/mips/kvm/mips.c @@ -199,7 +199,7 @@ void kvm_arch_flush_shadow_memslot(struct kvm *kvm, /* Flush slot from GPA */ kvm_mips_flush_gpa_pt(kvm, slot->base_gfn, slot->base_gfn + slot->npages - 1); - kvm_arch_flush_remote_tlbs_memslot(kvm, slot); + kvm_flush_remote_tlbs_memslot(kvm, slot); spin_unlock(&kvm->mmu_lock); } @@ -235,7 +235,7 @@ void kvm_arch_commit_memory_region(struct kvm *kvm, needs_flush = kvm_mips_mkclean_gpa_pt(kvm, new->base_gfn, new->base_gfn + new->npages - 1); if (needs_flush) - kvm_arch_flush_remote_tlbs_memslot(kvm, new); + kvm_flush_remote_tlbs_memslot(kvm, new); spin_unlock(&kvm->mmu_lock); } } @@ -987,12 +987,6 @@ int kvm_arch_flush_remote_tlbs(struct kvm *kvm) return 1; } -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot) -{ - kvm_flush_remote_tlbs(kvm); -} - long kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg) { long r; diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c index 66ef19676fe4..87f30487f59f 100644 --- a/arch/riscv/kvm/mmu.c +++ b/arch/riscv/kvm/mmu.c @@ -406,12 +406,6 @@ void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot) { } -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot) -{ - kvm_flush_remote_tlbs(kvm); -} - void kvm_arch_free_memslot(struct kvm *kvm, struct kvm_memory_slot *free) { } diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 491c28d22cbe..4af85888c98b 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -6528,7 +6528,7 @@ static void kvm_rmap_zap_collapsible_sptes(struct kvm *kvm, */ if (slot_handle_level(kvm, slot, kvm_mmu_zap_collapsible_spte, PG_LEVEL_4K, KVM_MAX_HUGEPAGE_LEVEL - 1, true)) - kvm_arch_flush_remote_tlbs_memslot(kvm, slot); + kvm_flush_remote_tlbs_memslot(kvm, slot); } void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm, @@ -6547,20 +6547,6 @@ void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm, } } -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot) -{ - /* - * All current use cases for flushing the TLBs for a specific memslot - * related to dirty logging, and many do the TLB flush out of mmu_lock. - * The interaction between the various operations on memslot must be - * serialized by slots_locks to ensure the TLB flush from one operation - * is observed by any other operation on the same memslot. - */ - lockdep_assert_held(&kvm->slots_lock); - kvm_flush_remote_tlbs_range(kvm, memslot->base_gfn, memslot->npages); -} - void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm, const struct kvm_memory_slot *memslot) { diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 508074e47bc0..ea7bb4035a60 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -12617,7 +12617,7 @@ static void kvm_mmu_slot_apply_flags(struct kvm *kvm, * See is_writable_pte() for more details (the case involving * access-tracked SPTEs is particularly relevant). */ - kvm_arch_flush_remote_tlbs_memslot(kvm, new); + kvm_flush_remote_tlbs_memslot(kvm, new); } } diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index acfb17d9b44d..12dfecd27c9d 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -1357,6 +1357,8 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *vcpu, bool usermode_vcpu_not_eligible); void kvm_flush_remote_tlbs(struct kvm *kvm); void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t gfn, u64 pages); +void kvm_flush_remote_tlbs_memslot(struct kvm *kvm, + const struct kvm_memory_slot *memslot); #ifdef KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE int kvm_mmu_topup_memory_cache(struct kvm_mmu_memory_cache *mc, int min); @@ -1385,10 +1387,7 @@ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm *kvm, unsigned long mask); void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot); -#ifdef CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot); -#else /* !CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT */ +#ifndef CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm, struct kvm_dirty_log *log); int kvm_get_dirty_log(struct kvm *kvm, struct kvm_dirty_log *log, int *is_dirty, struct kvm_memory_slot **memslot); diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index c9fc693a39d9..9c10cd191a71 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -381,6 +381,20 @@ void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t gfn, u64 pages) kvm_flush_remote_tlbs(kvm); } +void kvm_flush_remote_tlbs_memslot(struct kvm *kvm, + const struct kvm_memory_slot *memslot) +{ + /* + * All current use cases for flushing the TLBs for a specific memslot + * related to dirty logging, and many do the TLB flush out of mmu_lock. + * The interaction between the various operations on memslot must be + * serialized by slots_locks to ensure the TLB flush from one operation + * is observed by any other operation on the same memslot. + */ + lockdep_assert_held(&kvm->slots_lock); + kvm_flush_remote_tlbs_range(kvm, memslot->base_gfn, memslot->npages); +} + static void kvm_flush_shadow_all(struct kvm *kvm) { kvm_arch_flush_shadow_all(kvm); @@ -2188,7 +2202,7 @@ static int kvm_get_dirty_log_protect(struct kvm *kvm, struct kvm_dirty_log *log) } if (flush) - kvm_arch_flush_remote_tlbs_memslot(kvm, memslot); + kvm_flush_remote_tlbs_memslot(kvm, memslot); if (copy_to_user(log->dirty_bitmap, dirty_bitmap_buffer, n)) return -EFAULT; @@ -2305,7 +2319,7 @@ static int kvm_clear_dirty_log_protect(struct kvm *kvm, KVM_MMU_UNLOCK(kvm); if (flush) - kvm_arch_flush_remote_tlbs_memslot(kvm, memslot); + kvm_flush_remote_tlbs_memslot(kvm, memslot); return 0; } -- 2.39.0.246.g2a6d74b583-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 7/7] KVM: Move kvm_arch_flush_remote_tlbs_memslot() to common code @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Move kvm_arch_flush_remote_tlbs_memslot() to common code and drop "arch_" from the name. kvm_arch_flush_remote_tlbs_memslot() is just a range-based TLB invalidation where the range is defined by the memslot. Now that kvm_flush_remote_tlbs_range() can be called from common code we can just use that and drop a bunch of duplicate code from the arch directories. Note this adds a lockdep assertion for slots_lock being held when calling kvm_flush_remote_tlbs_memslot(), which was previously only asserted on x86. MIPS has calls to kvm_flush_remote_tlbs_memslot(), but they all hold the slots_lock, so the lockdep assertion continues to hold true. Also drop the CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT ifdef gating kvm_flush_remote_tlbs_memslot(), since it is no longer necessary. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/arm64/kvm/arm.c | 6 ------ arch/mips/kvm/mips.c | 10 ++-------- arch/riscv/kvm/mmu.c | 6 ------ arch/x86/kvm/mmu/mmu.c | 16 +--------------- arch/x86/kvm/x86.c | 2 +- include/linux/kvm_host.h | 7 +++---- virt/kvm/kvm_main.c | 18 ++++++++++++++++-- 7 files changed, 23 insertions(+), 42 deletions(-) diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index 698787ed87e9..54d5d0733b98 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -1420,12 +1420,6 @@ void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot) } -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot) -{ - kvm_flush_remote_tlbs(kvm); -} - static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm, struct kvm_arm_device_addr *dev_addr) { diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c index 2e54e5fd8daa..9f9a7ba7eb2b 100644 --- a/arch/mips/kvm/mips.c +++ b/arch/mips/kvm/mips.c @@ -199,7 +199,7 @@ void kvm_arch_flush_shadow_memslot(struct kvm *kvm, /* Flush slot from GPA */ kvm_mips_flush_gpa_pt(kvm, slot->base_gfn, slot->base_gfn + slot->npages - 1); - kvm_arch_flush_remote_tlbs_memslot(kvm, slot); + kvm_flush_remote_tlbs_memslot(kvm, slot); spin_unlock(&kvm->mmu_lock); } @@ -235,7 +235,7 @@ void kvm_arch_commit_memory_region(struct kvm *kvm, needs_flush = kvm_mips_mkclean_gpa_pt(kvm, new->base_gfn, new->base_gfn + new->npages - 1); if (needs_flush) - kvm_arch_flush_remote_tlbs_memslot(kvm, new); + kvm_flush_remote_tlbs_memslot(kvm, new); spin_unlock(&kvm->mmu_lock); } } @@ -987,12 +987,6 @@ int kvm_arch_flush_remote_tlbs(struct kvm *kvm) return 1; } -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot) -{ - kvm_flush_remote_tlbs(kvm); -} - long kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg) { long r; diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c index 66ef19676fe4..87f30487f59f 100644 --- a/arch/riscv/kvm/mmu.c +++ b/arch/riscv/kvm/mmu.c @@ -406,12 +406,6 @@ void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot) { } -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot) -{ - kvm_flush_remote_tlbs(kvm); -} - void kvm_arch_free_memslot(struct kvm *kvm, struct kvm_memory_slot *free) { } diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 491c28d22cbe..4af85888c98b 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -6528,7 +6528,7 @@ static void kvm_rmap_zap_collapsible_sptes(struct kvm *kvm, */ if (slot_handle_level(kvm, slot, kvm_mmu_zap_collapsible_spte, PG_LEVEL_4K, KVM_MAX_HUGEPAGE_LEVEL - 1, true)) - kvm_arch_flush_remote_tlbs_memslot(kvm, slot); + kvm_flush_remote_tlbs_memslot(kvm, slot); } void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm, @@ -6547,20 +6547,6 @@ void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm, } } -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot) -{ - /* - * All current use cases for flushing the TLBs for a specific memslot - * related to dirty logging, and many do the TLB flush out of mmu_lock. - * The interaction between the various operations on memslot must be - * serialized by slots_locks to ensure the TLB flush from one operation - * is observed by any other operation on the same memslot. - */ - lockdep_assert_held(&kvm->slots_lock); - kvm_flush_remote_tlbs_range(kvm, memslot->base_gfn, memslot->npages); -} - void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm, const struct kvm_memory_slot *memslot) { diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 508074e47bc0..ea7bb4035a60 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -12617,7 +12617,7 @@ static void kvm_mmu_slot_apply_flags(struct kvm *kvm, * See is_writable_pte() for more details (the case involving * access-tracked SPTEs is particularly relevant). */ - kvm_arch_flush_remote_tlbs_memslot(kvm, new); + kvm_flush_remote_tlbs_memslot(kvm, new); } } diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index acfb17d9b44d..12dfecd27c9d 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -1357,6 +1357,8 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *vcpu, bool usermode_vcpu_not_eligible); void kvm_flush_remote_tlbs(struct kvm *kvm); void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t gfn, u64 pages); +void kvm_flush_remote_tlbs_memslot(struct kvm *kvm, + const struct kvm_memory_slot *memslot); #ifdef KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE int kvm_mmu_topup_memory_cache(struct kvm_mmu_memory_cache *mc, int min); @@ -1385,10 +1387,7 @@ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm *kvm, unsigned long mask); void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot); -#ifdef CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot); -#else /* !CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT */ +#ifndef CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm, struct kvm_dirty_log *log); int kvm_get_dirty_log(struct kvm *kvm, struct kvm_dirty_log *log, int *is_dirty, struct kvm_memory_slot **memslot); diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index c9fc693a39d9..9c10cd191a71 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -381,6 +381,20 @@ void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t gfn, u64 pages) kvm_flush_remote_tlbs(kvm); } +void kvm_flush_remote_tlbs_memslot(struct kvm *kvm, + const struct kvm_memory_slot *memslot) +{ + /* + * All current use cases for flushing the TLBs for a specific memslot + * related to dirty logging, and many do the TLB flush out of mmu_lock. + * The interaction between the various operations on memslot must be + * serialized by slots_locks to ensure the TLB flush from one operation + * is observed by any other operation on the same memslot. + */ + lockdep_assert_held(&kvm->slots_lock); + kvm_flush_remote_tlbs_range(kvm, memslot->base_gfn, memslot->npages); +} + static void kvm_flush_shadow_all(struct kvm *kvm) { kvm_arch_flush_shadow_all(kvm); @@ -2188,7 +2202,7 @@ static int kvm_get_dirty_log_protect(struct kvm *kvm, struct kvm_dirty_log *log) } if (flush) - kvm_arch_flush_remote_tlbs_memslot(kvm, memslot); + kvm_flush_remote_tlbs_memslot(kvm, memslot); if (copy_to_user(log->dirty_bitmap, dirty_bitmap_buffer, n)) return -EFAULT; @@ -2305,7 +2319,7 @@ static int kvm_clear_dirty_log_protect(struct kvm *kvm, KVM_MMU_UNLOCK(kvm); if (flush) - kvm_arch_flush_remote_tlbs_memslot(kvm, memslot); + kvm_flush_remote_tlbs_memslot(kvm, memslot); return 0; } -- 2.39.0.246.g2a6d74b583-goog _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 7/7] KVM: Move kvm_arch_flush_remote_tlbs_memslot() to common code @ 2023-01-19 17:35 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-19 17:35 UTC (permalink / raw) To: Paolo Bonzini Cc: Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, Sean Christopherson, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, David Matlack, Raghavendra Rao Ananta Move kvm_arch_flush_remote_tlbs_memslot() to common code and drop "arch_" from the name. kvm_arch_flush_remote_tlbs_memslot() is just a range-based TLB invalidation where the range is defined by the memslot. Now that kvm_flush_remote_tlbs_range() can be called from common code we can just use that and drop a bunch of duplicate code from the arch directories. Note this adds a lockdep assertion for slots_lock being held when calling kvm_flush_remote_tlbs_memslot(), which was previously only asserted on x86. MIPS has calls to kvm_flush_remote_tlbs_memslot(), but they all hold the slots_lock, so the lockdep assertion continues to hold true. Also drop the CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT ifdef gating kvm_flush_remote_tlbs_memslot(), since it is no longer necessary. Signed-off-by: David Matlack <dmatlack@google.com> --- arch/arm64/kvm/arm.c | 6 ------ arch/mips/kvm/mips.c | 10 ++-------- arch/riscv/kvm/mmu.c | 6 ------ arch/x86/kvm/mmu/mmu.c | 16 +--------------- arch/x86/kvm/x86.c | 2 +- include/linux/kvm_host.h | 7 +++---- virt/kvm/kvm_main.c | 18 ++++++++++++++++-- 7 files changed, 23 insertions(+), 42 deletions(-) diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index 698787ed87e9..54d5d0733b98 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -1420,12 +1420,6 @@ void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot) } -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot) -{ - kvm_flush_remote_tlbs(kvm); -} - static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm, struct kvm_arm_device_addr *dev_addr) { diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c index 2e54e5fd8daa..9f9a7ba7eb2b 100644 --- a/arch/mips/kvm/mips.c +++ b/arch/mips/kvm/mips.c @@ -199,7 +199,7 @@ void kvm_arch_flush_shadow_memslot(struct kvm *kvm, /* Flush slot from GPA */ kvm_mips_flush_gpa_pt(kvm, slot->base_gfn, slot->base_gfn + slot->npages - 1); - kvm_arch_flush_remote_tlbs_memslot(kvm, slot); + kvm_flush_remote_tlbs_memslot(kvm, slot); spin_unlock(&kvm->mmu_lock); } @@ -235,7 +235,7 @@ void kvm_arch_commit_memory_region(struct kvm *kvm, needs_flush = kvm_mips_mkclean_gpa_pt(kvm, new->base_gfn, new->base_gfn + new->npages - 1); if (needs_flush) - kvm_arch_flush_remote_tlbs_memslot(kvm, new); + kvm_flush_remote_tlbs_memslot(kvm, new); spin_unlock(&kvm->mmu_lock); } } @@ -987,12 +987,6 @@ int kvm_arch_flush_remote_tlbs(struct kvm *kvm) return 1; } -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot) -{ - kvm_flush_remote_tlbs(kvm); -} - long kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg) { long r; diff --git a/arch/riscv/kvm/mmu.c b/arch/riscv/kvm/mmu.c index 66ef19676fe4..87f30487f59f 100644 --- a/arch/riscv/kvm/mmu.c +++ b/arch/riscv/kvm/mmu.c @@ -406,12 +406,6 @@ void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot) { } -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot) -{ - kvm_flush_remote_tlbs(kvm); -} - void kvm_arch_free_memslot(struct kvm *kvm, struct kvm_memory_slot *free) { } diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c index 491c28d22cbe..4af85888c98b 100644 --- a/arch/x86/kvm/mmu/mmu.c +++ b/arch/x86/kvm/mmu/mmu.c @@ -6528,7 +6528,7 @@ static void kvm_rmap_zap_collapsible_sptes(struct kvm *kvm, */ if (slot_handle_level(kvm, slot, kvm_mmu_zap_collapsible_spte, PG_LEVEL_4K, KVM_MAX_HUGEPAGE_LEVEL - 1, true)) - kvm_arch_flush_remote_tlbs_memslot(kvm, slot); + kvm_flush_remote_tlbs_memslot(kvm, slot); } void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm, @@ -6547,20 +6547,6 @@ void kvm_mmu_zap_collapsible_sptes(struct kvm *kvm, } } -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot) -{ - /* - * All current use cases for flushing the TLBs for a specific memslot - * related to dirty logging, and many do the TLB flush out of mmu_lock. - * The interaction between the various operations on memslot must be - * serialized by slots_locks to ensure the TLB flush from one operation - * is observed by any other operation on the same memslot. - */ - lockdep_assert_held(&kvm->slots_lock); - kvm_flush_remote_tlbs_range(kvm, memslot->base_gfn, memslot->npages); -} - void kvm_mmu_slot_leaf_clear_dirty(struct kvm *kvm, const struct kvm_memory_slot *memslot) { diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 508074e47bc0..ea7bb4035a60 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -12617,7 +12617,7 @@ static void kvm_mmu_slot_apply_flags(struct kvm *kvm, * See is_writable_pte() for more details (the case involving * access-tracked SPTEs is particularly relevant). */ - kvm_arch_flush_remote_tlbs_memslot(kvm, new); + kvm_flush_remote_tlbs_memslot(kvm, new); } } diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index acfb17d9b44d..12dfecd27c9d 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -1357,6 +1357,8 @@ void kvm_vcpu_on_spin(struct kvm_vcpu *vcpu, bool usermode_vcpu_not_eligible); void kvm_flush_remote_tlbs(struct kvm *kvm); void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t gfn, u64 pages); +void kvm_flush_remote_tlbs_memslot(struct kvm *kvm, + const struct kvm_memory_slot *memslot); #ifdef KVM_ARCH_NR_OBJS_PER_MEMORY_CACHE int kvm_mmu_topup_memory_cache(struct kvm_mmu_memory_cache *mc, int min); @@ -1385,10 +1387,7 @@ void kvm_arch_mmu_enable_log_dirty_pt_masked(struct kvm *kvm, unsigned long mask); void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot); -#ifdef CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT -void kvm_arch_flush_remote_tlbs_memslot(struct kvm *kvm, - const struct kvm_memory_slot *memslot); -#else /* !CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT */ +#ifndef CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT int kvm_vm_ioctl_get_dirty_log(struct kvm *kvm, struct kvm_dirty_log *log); int kvm_get_dirty_log(struct kvm *kvm, struct kvm_dirty_log *log, int *is_dirty, struct kvm_memory_slot **memslot); diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index c9fc693a39d9..9c10cd191a71 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -381,6 +381,20 @@ void kvm_flush_remote_tlbs_range(struct kvm *kvm, gfn_t gfn, u64 pages) kvm_flush_remote_tlbs(kvm); } +void kvm_flush_remote_tlbs_memslot(struct kvm *kvm, + const struct kvm_memory_slot *memslot) +{ + /* + * All current use cases for flushing the TLBs for a specific memslot + * related to dirty logging, and many do the TLB flush out of mmu_lock. + * The interaction between the various operations on memslot must be + * serialized by slots_locks to ensure the TLB flush from one operation + * is observed by any other operation on the same memslot. + */ + lockdep_assert_held(&kvm->slots_lock); + kvm_flush_remote_tlbs_range(kvm, memslot->base_gfn, memslot->npages); +} + static void kvm_flush_shadow_all(struct kvm *kvm) { kvm_arch_flush_shadow_all(kvm); @@ -2188,7 +2202,7 @@ static int kvm_get_dirty_log_protect(struct kvm *kvm, struct kvm_dirty_log *log) } if (flush) - kvm_arch_flush_remote_tlbs_memslot(kvm, memslot); + kvm_flush_remote_tlbs_memslot(kvm, memslot); if (copy_to_user(log->dirty_bitmap, dirty_bitmap_buffer, n)) return -EFAULT; @@ -2305,7 +2319,7 @@ static int kvm_clear_dirty_log_protect(struct kvm *kvm, KVM_MMU_UNLOCK(kvm); if (flush) - kvm_arch_flush_remote_tlbs_memslot(kvm, memslot); + kvm_flush_remote_tlbs_memslot(kvm, memslot); return 0; } -- 2.39.0.246.g2a6d74b583-goog ^ permalink raw reply related [flat|nested] 64+ messages in thread
* [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation 2023-01-19 17:35 ` David Matlack (?) (?) @ 2023-01-25 0:46 ` Sean Christopherson -1 siblings, 0 replies; 64+ messages in thread From: Sean Christopherson @ 2023-01-25 0:46 UTC (permalink / raw) To: kvm-riscv On Thu, Jan 19, 2023, David Matlack wrote: > This series introduces a common API for performing range-based TLB > invalidation. This is then used to supplant > kvm_arch_flush_remote_tlbs_memslot() and pave the way for two other > patch series: > > 1. https://lore.kernel.org/kvm/20230109215347.3119271-1-rananta at google.com/ > > Adds ARM support for range-based TLB invalidation and needs a > mechanism to invoke it from common code. This series provides such a > mechanism via kvm_arch_flush_remote_tlbs_range(). > > 2. https://lore.kernel.org/kvm/20221208193857.4090582-1-dmatlack at google.com/ > > Refactors the TDP MMU into common code, which requires an API for > range-based TLB invaliation. > > This series is based on patches 29-33 from (2.), but I made some further > cleanups after looking at it a second time. > > Tested on x86_64 and ARM64 using KVM selftests. Did a quick read through, didn't see anything I disagree with. Is there any urgency to getting this merged? If not, due to the dependencies with x86 stuff queued for 6.3, and because of the cross-architecture changes, it might be easiest to plan on landing this in 6.4. That would allow Paolo to create an immutable topic branch fairly early on. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation @ 2023-01-25 0:46 ` Sean Christopherson 0 siblings, 0 replies; 64+ messages in thread From: Sean Christopherson @ 2023-01-25 0:46 UTC (permalink / raw) To: David Matlack Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Thu, Jan 19, 2023, David Matlack wrote: > This series introduces a common API for performing range-based TLB > invalidation. This is then used to supplant > kvm_arch_flush_remote_tlbs_memslot() and pave the way for two other > patch series: > > 1. https://lore.kernel.org/kvm/20230109215347.3119271-1-rananta@google.com/ > > Adds ARM support for range-based TLB invalidation and needs a > mechanism to invoke it from common code. This series provides such a > mechanism via kvm_arch_flush_remote_tlbs_range(). > > 2. https://lore.kernel.org/kvm/20221208193857.4090582-1-dmatlack@google.com/ > > Refactors the TDP MMU into common code, which requires an API for > range-based TLB invaliation. > > This series is based on patches 29-33 from (2.), but I made some further > cleanups after looking at it a second time. > > Tested on x86_64 and ARM64 using KVM selftests. Did a quick read through, didn't see anything I disagree with. Is there any urgency to getting this merged? If not, due to the dependencies with x86 stuff queued for 6.3, and because of the cross-architecture changes, it might be easiest to plan on landing this in 6.4. That would allow Paolo to create an immutable topic branch fairly early on. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation @ 2023-01-25 0:46 ` Sean Christopherson 0 siblings, 0 replies; 64+ messages in thread From: Sean Christopherson @ 2023-01-25 0:46 UTC (permalink / raw) To: David Matlack Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Thu, Jan 19, 2023, David Matlack wrote: > This series introduces a common API for performing range-based TLB > invalidation. This is then used to supplant > kvm_arch_flush_remote_tlbs_memslot() and pave the way for two other > patch series: > > 1. https://lore.kernel.org/kvm/20230109215347.3119271-1-rananta@google.com/ > > Adds ARM support for range-based TLB invalidation and needs a > mechanism to invoke it from common code. This series provides such a > mechanism via kvm_arch_flush_remote_tlbs_range(). > > 2. https://lore.kernel.org/kvm/20221208193857.4090582-1-dmatlack@google.com/ > > Refactors the TDP MMU into common code, which requires an API for > range-based TLB invaliation. > > This series is based on patches 29-33 from (2.), but I made some further > cleanups after looking at it a second time. > > Tested on x86_64 and ARM64 using KVM selftests. Did a quick read through, didn't see anything I disagree with. Is there any urgency to getting this merged? If not, due to the dependencies with x86 stuff queued for 6.3, and because of the cross-architecture changes, it might be easiest to plan on landing this in 6.4. That would allow Paolo to create an immutable topic branch fairly early on. _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation @ 2023-01-25 0:46 ` Sean Christopherson 0 siblings, 0 replies; 64+ messages in thread From: Sean Christopherson @ 2023-01-25 0:46 UTC (permalink / raw) To: David Matlack Cc: Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Oliver Upton, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Thu, Jan 19, 2023, David Matlack wrote: > This series introduces a common API for performing range-based TLB > invalidation. This is then used to supplant > kvm_arch_flush_remote_tlbs_memslot() and pave the way for two other > patch series: > > 1. https://lore.kernel.org/kvm/20230109215347.3119271-1-rananta@google.com/ > > Adds ARM support for range-based TLB invalidation and needs a > mechanism to invoke it from common code. This series provides such a > mechanism via kvm_arch_flush_remote_tlbs_range(). > > 2. https://lore.kernel.org/kvm/20221208193857.4090582-1-dmatlack@google.com/ > > Refactors the TDP MMU into common code, which requires an API for > range-based TLB invaliation. > > This series is based on patches 29-33 from (2.), but I made some further > cleanups after looking at it a second time. > > Tested on x86_64 and ARM64 using KVM selftests. Did a quick read through, didn't see anything I disagree with. Is there any urgency to getting this merged? If not, due to the dependencies with x86 stuff queued for 6.3, and because of the cross-architecture changes, it might be easiest to plan on landing this in 6.4. That would allow Paolo to create an immutable topic branch fairly early on. ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation 2023-01-25 0:46 ` Sean Christopherson (?) (?) @ 2023-01-25 0:51 ` Oliver Upton -1 siblings, 0 replies; 64+ messages in thread From: Oliver Upton @ 2023-01-25 0:51 UTC (permalink / raw) To: kvm-riscv On Wed, Jan 25, 2023 at 12:46:59AM +0000, Sean Christopherson wrote: > On Thu, Jan 19, 2023, David Matlack wrote: > > This series introduces a common API for performing range-based TLB > > invalidation. This is then used to supplant > > kvm_arch_flush_remote_tlbs_memslot() and pave the way for two other > > patch series: > > > > 1. https://lore.kernel.org/kvm/20230109215347.3119271-1-rananta at google.com/ > > > > Adds ARM support for range-based TLB invalidation and needs a > > mechanism to invoke it from common code. This series provides such a > > mechanism via kvm_arch_flush_remote_tlbs_range(). > > > > 2. https://lore.kernel.org/kvm/20221208193857.4090582-1-dmatlack at google.com/ > > > > Refactors the TDP MMU into common code, which requires an API for > > range-based TLB invaliation. > > > > This series is based on patches 29-33 from (2.), but I made some further > > cleanups after looking at it a second time. > > > > Tested on x86_64 and ARM64 using KVM selftests. > > Did a quick read through, didn't see anything I disagree with. LGTM for the tiny amount of arm64 changes, though I imagine David will do a v2 to completely get rid of the affected Kconfig. > Is there any urgency to getting this merged? If not, due to the dependencies > with x86 stuff queued for 6.3, and because of the cross-architecture changes, it > might be easiest to plan on landing this in 6.4. That would allow Paolo to create > an immutable topic branch fairly early on. +1, that buys us some time to go through the rounds on the arm64 side such that we could possibly stack the TLBIRANGE work on top. -- Thanks, Oliver ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation @ 2023-01-25 0:51 ` Oliver Upton 0 siblings, 0 replies; 64+ messages in thread From: Oliver Upton @ 2023-01-25 0:51 UTC (permalink / raw) To: Sean Christopherson Cc: David Matlack, Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Wed, Jan 25, 2023 at 12:46:59AM +0000, Sean Christopherson wrote: > On Thu, Jan 19, 2023, David Matlack wrote: > > This series introduces a common API for performing range-based TLB > > invalidation. This is then used to supplant > > kvm_arch_flush_remote_tlbs_memslot() and pave the way for two other > > patch series: > > > > 1. https://lore.kernel.org/kvm/20230109215347.3119271-1-rananta@google.com/ > > > > Adds ARM support for range-based TLB invalidation and needs a > > mechanism to invoke it from common code. This series provides such a > > mechanism via kvm_arch_flush_remote_tlbs_range(). > > > > 2. https://lore.kernel.org/kvm/20221208193857.4090582-1-dmatlack@google.com/ > > > > Refactors the TDP MMU into common code, which requires an API for > > range-based TLB invaliation. > > > > This series is based on patches 29-33 from (2.), but I made some further > > cleanups after looking at it a second time. > > > > Tested on x86_64 and ARM64 using KVM selftests. > > Did a quick read through, didn't see anything I disagree with. LGTM for the tiny amount of arm64 changes, though I imagine David will do a v2 to completely get rid of the affected Kconfig. > Is there any urgency to getting this merged? If not, due to the dependencies > with x86 stuff queued for 6.3, and because of the cross-architecture changes, it > might be easiest to plan on landing this in 6.4. That would allow Paolo to create > an immutable topic branch fairly early on. +1, that buys us some time to go through the rounds on the arm64 side such that we could possibly stack the TLBIRANGE work on top. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation @ 2023-01-25 0:51 ` Oliver Upton 0 siblings, 0 replies; 64+ messages in thread From: Oliver Upton @ 2023-01-25 0:51 UTC (permalink / raw) To: Sean Christopherson Cc: David Matlack, Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Wed, Jan 25, 2023 at 12:46:59AM +0000, Sean Christopherson wrote: > On Thu, Jan 19, 2023, David Matlack wrote: > > This series introduces a common API for performing range-based TLB > > invalidation. This is then used to supplant > > kvm_arch_flush_remote_tlbs_memslot() and pave the way for two other > > patch series: > > > > 1. https://lore.kernel.org/kvm/20230109215347.3119271-1-rananta@google.com/ > > > > Adds ARM support for range-based TLB invalidation and needs a > > mechanism to invoke it from common code. This series provides such a > > mechanism via kvm_arch_flush_remote_tlbs_range(). > > > > 2. https://lore.kernel.org/kvm/20221208193857.4090582-1-dmatlack@google.com/ > > > > Refactors the TDP MMU into common code, which requires an API for > > range-based TLB invaliation. > > > > This series is based on patches 29-33 from (2.), but I made some further > > cleanups after looking at it a second time. > > > > Tested on x86_64 and ARM64 using KVM selftests. > > Did a quick read through, didn't see anything I disagree with. LGTM for the tiny amount of arm64 changes, though I imagine David will do a v2 to completely get rid of the affected Kconfig. > Is there any urgency to getting this merged? If not, due to the dependencies > with x86 stuff queued for 6.3, and because of the cross-architecture changes, it > might be easiest to plan on landing this in 6.4. That would allow Paolo to create > an immutable topic branch fairly early on. +1, that buys us some time to go through the rounds on the arm64 side such that we could possibly stack the TLBIRANGE work on top. -- Thanks, Oliver _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation @ 2023-01-25 0:51 ` Oliver Upton 0 siblings, 0 replies; 64+ messages in thread From: Oliver Upton @ 2023-01-25 0:51 UTC (permalink / raw) To: Sean Christopherson Cc: David Matlack, Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Wed, Jan 25, 2023 at 12:46:59AM +0000, Sean Christopherson wrote: > On Thu, Jan 19, 2023, David Matlack wrote: > > This series introduces a common API for performing range-based TLB > > invalidation. This is then used to supplant > > kvm_arch_flush_remote_tlbs_memslot() and pave the way for two other > > patch series: > > > > 1. https://lore.kernel.org/kvm/20230109215347.3119271-1-rananta@google.com/ > > > > Adds ARM support for range-based TLB invalidation and needs a > > mechanism to invoke it from common code. This series provides such a > > mechanism via kvm_arch_flush_remote_tlbs_range(). > > > > 2. https://lore.kernel.org/kvm/20221208193857.4090582-1-dmatlack@google.com/ > > > > Refactors the TDP MMU into common code, which requires an API for > > range-based TLB invaliation. > > > > This series is based on patches 29-33 from (2.), but I made some further > > cleanups after looking at it a second time. > > > > Tested on x86_64 and ARM64 using KVM selftests. > > Did a quick read through, didn't see anything I disagree with. LGTM for the tiny amount of arm64 changes, though I imagine David will do a v2 to completely get rid of the affected Kconfig. > Is there any urgency to getting this merged? If not, due to the dependencies > with x86 stuff queued for 6.3, and because of the cross-architecture changes, it > might be easiest to plan on landing this in 6.4. That would allow Paolo to create > an immutable topic branch fairly early on. +1, that buys us some time to go through the rounds on the arm64 side such that we could possibly stack the TLBIRANGE work on top. -- Thanks, Oliver ^ permalink raw reply [flat|nested] 64+ messages in thread
* [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation 2023-01-25 0:51 ` Oliver Upton (?) (?) @ 2023-01-25 17:21 ` David Matlack -1 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-25 17:21 UTC (permalink / raw) To: kvm-riscv On Tue, Jan 24, 2023 at 4:51 PM Oliver Upton <oliver.upton@linux.dev> wrote: > On Wed, Jan 25, 2023 at 12:46:59AM +0000, Sean Christopherson wrote: > > On Thu, Jan 19, 2023, David Matlack wrote: > > > > Did a quick read through, didn't see anything I disagree with. > > LGTM for the tiny amount of arm64 changes, though I imagine David will > do a v2 to completely get rid of the affected Kconfig. Thanks both for taking a look. > > Is there any urgency to getting this merged? If not, due to the dependencies > > with x86 stuff queued for 6.3, and because of the cross-architecture changes, it > > might be easiest to plan on landing this in 6.4. That would allow Paolo to create > > an immutable topic branch fairly early on. > > +1, that buys us some time to go through the rounds on the arm64 side > such that we could possibly stack the TLBIRANGE work on top. The main benefit of merging in 6.3 would be to make Raghavendra's life simpler/easier so he can build the next version of his arm64 TLBI series on top. But I guess he can still do that with a topic branch. I'll go ahead and send a v2 on top of the changes from Hou you queued for 6.3, Sean, and we can plan on landing that in 6.4 (barring any further feedback or conflicts). ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation @ 2023-01-25 17:21 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-25 17:21 UTC (permalink / raw) To: Oliver Upton Cc: Sean Christopherson, Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Tue, Jan 24, 2023 at 4:51 PM Oliver Upton <oliver.upton@linux.dev> wrote: > On Wed, Jan 25, 2023 at 12:46:59AM +0000, Sean Christopherson wrote: > > On Thu, Jan 19, 2023, David Matlack wrote: > > > > Did a quick read through, didn't see anything I disagree with. > > LGTM for the tiny amount of arm64 changes, though I imagine David will > do a v2 to completely get rid of the affected Kconfig. Thanks both for taking a look. > > Is there any urgency to getting this merged? If not, due to the dependencies > > with x86 stuff queued for 6.3, and because of the cross-architecture changes, it > > might be easiest to plan on landing this in 6.4. That would allow Paolo to create > > an immutable topic branch fairly early on. > > +1, that buys us some time to go through the rounds on the arm64 side > such that we could possibly stack the TLBIRANGE work on top. The main benefit of merging in 6.3 would be to make Raghavendra's life simpler/easier so he can build the next version of his arm64 TLBI series on top. But I guess he can still do that with a topic branch. I'll go ahead and send a v2 on top of the changes from Hou you queued for 6.3, Sean, and we can plan on landing that in 6.4 (barring any further feedback or conflicts). _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation @ 2023-01-25 17:21 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-25 17:21 UTC (permalink / raw) To: Oliver Upton Cc: Sean Christopherson, Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Tue, Jan 24, 2023 at 4:51 PM Oliver Upton <oliver.upton@linux.dev> wrote: > On Wed, Jan 25, 2023 at 12:46:59AM +0000, Sean Christopherson wrote: > > On Thu, Jan 19, 2023, David Matlack wrote: > > > > Did a quick read through, didn't see anything I disagree with. > > LGTM for the tiny amount of arm64 changes, though I imagine David will > do a v2 to completely get rid of the affected Kconfig. Thanks both for taking a look. > > Is there any urgency to getting this merged? If not, due to the dependencies > > with x86 stuff queued for 6.3, and because of the cross-architecture changes, it > > might be easiest to plan on landing this in 6.4. That would allow Paolo to create > > an immutable topic branch fairly early on. > > +1, that buys us some time to go through the rounds on the arm64 side > such that we could possibly stack the TLBIRANGE work on top. The main benefit of merging in 6.3 would be to make Raghavendra's life simpler/easier so he can build the next version of his arm64 TLBI series on top. But I guess he can still do that with a topic branch. I'll go ahead and send a v2 on top of the changes from Hou you queued for 6.3, Sean, and we can plan on landing that in 6.4 (barring any further feedback or conflicts). _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation @ 2023-01-25 17:21 ` David Matlack 0 siblings, 0 replies; 64+ messages in thread From: David Matlack @ 2023-01-25 17:21 UTC (permalink / raw) To: Oliver Upton Cc: Sean Christopherson, Paolo Bonzini, Marc Zyngier, James Morse, Suzuki K Poulose, Zenghui Yu, Huacai Chen, Aleksandar Markovic, Anup Patel, Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou, linux-arm-kernel, kvmarm, kvmarm, linux-mips, kvm, kvm-riscv, linux-riscv, Raghavendra Rao Ananta On Tue, Jan 24, 2023 at 4:51 PM Oliver Upton <oliver.upton@linux.dev> wrote: > On Wed, Jan 25, 2023 at 12:46:59AM +0000, Sean Christopherson wrote: > > On Thu, Jan 19, 2023, David Matlack wrote: > > > > Did a quick read through, didn't see anything I disagree with. > > LGTM for the tiny amount of arm64 changes, though I imagine David will > do a v2 to completely get rid of the affected Kconfig. Thanks both for taking a look. > > Is there any urgency to getting this merged? If not, due to the dependencies > > with x86 stuff queued for 6.3, and because of the cross-architecture changes, it > > might be easiest to plan on landing this in 6.4. That would allow Paolo to create > > an immutable topic branch fairly early on. > > +1, that buys us some time to go through the rounds on the arm64 side > such that we could possibly stack the TLBIRANGE work on top. The main benefit of merging in 6.3 would be to make Raghavendra's life simpler/easier so he can build the next version of his arm64 TLBI series on top. But I guess he can still do that with a topic branch. I'll go ahead and send a v2 on top of the changes from Hou you queued for 6.3, Sean, and we can plan on landing that in 6.4 (barring any further feedback or conflicts). ^ permalink raw reply [flat|nested] 64+ messages in thread
end of thread, other threads:[~2023-01-25 17:23 UTC | newest]
Thread overview: 64+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-01-19 17:35 [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` [PATCH 1/7] KVM: Rename kvm_arch_flush_remote_tlb() to kvm_arch_flush_remote_tlbs() David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` [PATCH 2/7] KVM: arm64: Use kvm_arch_flush_remote_tlbs() David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-24 17:17 ` Oliver Upton
2023-01-24 17:17 ` Oliver Upton
2023-01-24 17:17 ` Oliver Upton
2023-01-24 17:17 ` Oliver Upton
2023-01-24 17:28 ` David Matlack
2023-01-24 17:28 ` David Matlack
2023-01-24 17:28 ` David Matlack
2023-01-24 17:28 ` David Matlack
2023-01-19 17:35 ` [PATCH 3/7] KVM: x86/mmu: Collapse kvm_flush_remote_tlbs_with_{range,address}() together David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` [PATCH 4/7] KVM: x86/mmu: Rename kvm_flush_remote_tlbs_with_address() David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 18:17 ` Sean Christopherson
2023-01-19 18:17 ` Sean Christopherson
2023-01-19 18:17 ` Sean Christopherson
2023-01-19 18:17 ` Sean Christopherson
2023-01-19 18:26 ` David Matlack
2023-01-19 18:26 ` David Matlack
2023-01-19 18:26 ` David Matlack
2023-01-19 18:26 ` David Matlack
2023-01-19 17:35 ` [PATCH 5/7] KVM: x86/MMU: Use gfn_t in kvm_flush_remote_tlbs_range() David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` [PATCH 6/7] KVM: Allow range-based TLB invalidation from common code David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-24 17:17 ` Oliver Upton
2023-01-24 17:17 ` Oliver Upton
2023-01-24 17:17 ` Oliver Upton
2023-01-24 17:17 ` Oliver Upton
2023-01-19 17:35 ` [PATCH 7/7] KVM: Move kvm_arch_flush_remote_tlbs_memslot() to " David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-19 17:35 ` David Matlack
2023-01-25 0:46 ` [PATCH 0/7] KVM: Add a common API for range-based TLB invalidation Sean Christopherson
2023-01-25 0:46 ` Sean Christopherson
2023-01-25 0:46 ` Sean Christopherson
2023-01-25 0:46 ` Sean Christopherson
2023-01-25 0:51 ` Oliver Upton
2023-01-25 0:51 ` Oliver Upton
2023-01-25 0:51 ` Oliver Upton
2023-01-25 0:51 ` Oliver Upton
2023-01-25 17:21 ` David Matlack
2023-01-25 17:21 ` David Matlack
2023-01-25 17:21 ` David Matlack
2023-01-25 17:21 ` David Matlack
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.