On Fri, Jun 24, 2022, Hou Wenlong wrote:
> Commit c3134ce240eed
> ("KVM: Replace old tlb flush function with new one to flush a specified range.")
> replaces old tlb flush function with kvm_flush_remote_tlbs_with_address()
> to do tlb flushing. However, the gfn range of tlb flushing is wrong in
> some cases. E.g., when a spte is dropped, the start gfn of tlb flushing
Heh, "some" cases. Looks like KVM is wrong on 7 of 15 cases. And IIRC, there
were already several rounds of fixes due to passing "end" instead of "nr_pages".
Patches look ok on a quick read through, but I'd have to stare a bunch more to
be confident.
Part of me wonders if we should just revert the whole thing and then only reintroduce
range-based flushing with proper testing and maybe even require performance numbers
to justify the benefits. Give that almost 50% of the users are broken, it's pretty
obvious that no one running KVM actually tests the behavior.
> should be the gfn of spte not the base gfn of SP which contains the spte.
> So this patchset would fix them and do some cleanups.
>
> Hou Wenlong (5):
> KVM: x86/mmu: Fix wrong gfn range of tlb flushing in
> validate_direct_spte()
> KVM: x86/mmu: Fix wrong gfn range of tlb flushing in
> kvm_set_pte_rmapp()
> KVM: x86/mmu: Reduce gfn range of tlb flushing in
> tdp_mmu_map_handle_target_level()
> KVM: x86/mmu: Fix wrong start gfn of tlb flushing with range
> KVM: x86/mmu: Use 1 as the size of gfn range for tlb flushing in
> FNAME(invlpg)()
>
> arch/x86/kvm/mmu/mmu.c | 15 +++++++++------
> arch/x86/kvm/mmu/paging_tmpl.h | 2 +-
> arch/x86/kvm/mmu/tdp_mmu.c | 4 ++--
> 3 files changed, 12 insertions(+), 9 deletions(-)
>
> --
> 2.31.1
>
