KVM: Kill kvm_map_gfn() / kvm_unmap_gfn() and gfn_to_pfn_cache
authorDavid Woodhouse <dwmw@amazon.co.uk>
Mon, 15 Nov 2021 16:50:27 +0000 (16:50 +0000)
committerPaolo Bonzini <pbonzini@redhat.com>
Thu, 18 Nov 2021 07:03:45 +0000 (02:03 -0500)
commit357a18ad230f0867791b788d2b1d6f280f6f6e61
tree2281ebb8d7f2f2cf48f1ea72c257324d94b77254
parentcee66664dcd6241a943380ef9dcd2f8a0a7dc47d
KVM: Kill kvm_map_gfn() / kvm_unmap_gfn() and gfn_to_pfn_cache

In commit 7e2175ebd695 ("KVM: x86: Fix recording of guest steal time /
preempted status") I removed the only user of these functions because
it was basically impossible to use them safely.

There are two stages to the GFN->PFN mapping; first through the KVM
memslots to a userspace HVA and then through the page tables to
translate that HVA to an underlying PFN. Invalidations of the former
were being handled correctly, but no attempt was made to use the MMU
notifiers to invalidate the cache when the HVA->GFN mapping changed.

As a prelude to reinventing the gfn_to_pfn_cache with more usable
semantics, rip it out entirely and untangle the implementation of
the unsafe kvm_vcpu_map()/kvm_vcpu_unmap() functions from it.

All current users of kvm_vcpu_map() also look broken right now, and
will be dealt with separately. They broadly fall into two classes:

* Those which map, access the data and immediately unmap. This is
  mostly gratuitous and could just as well use the existing user
  HVA, and could probably benefit from a gfn_to_hva_cache as they
  do so.

* Those which keep the mapping around for a longer time, perhaps
  even using the PFN directly from the guest. These will need to
  be converted to the new gfn_to_pfn_cache and then kvm_vcpu_map()
  can be removed too.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Message-Id: <20211115165030.7422-8-dwmw2@infradead.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
include/linux/kvm_host.h
include/linux/kvm_types.h
virt/kvm/kvm_main.c