diff options
author | Sean Christopherson <seanjc@google.com> | 2022-10-13 21:12:29 +0000 |
---|---|---|
committer | David Woodhouse <dwmw@amazon.co.uk> | 2022-11-30 19:25:24 +0000 |
commit | 9f87791d686d85614584438d4f249eb32ef7964c (patch) | |
tree | c2c4a01fd11883c843242ad0a3035fd7754809fa /mm/userfaultfd.c | |
parent | 0318f207d1c2e297d1ec1c6e145bb8bd053236f9 (diff) | |
download | linux-9f87791d686d85614584438d4f249eb32ef7964c.tar.gz linux-9f87791d686d85614584438d4f249eb32ef7964c.tar.bz2 linux-9f87791d686d85614584438d4f249eb32ef7964c.zip |
KVM: Drop KVM's API to allow temporarily unmapping gfn=>pfn cache
Drop kvm_gpc_unmap() as it has no users and unclear requirements. The
API was added as part of the original gfn_to_pfn_cache support, but its
sole usage[*] was never merged. Fold the guts of kvm_gpc_unmap() into
the deactivate path and drop the API. Omit acquiring refresh_lock as
as concurrent calls to kvm_gpc_deactivate() are not allowed (this is
not enforced, e.g. via lockdep. due to it being called during vCPU
destruction).
If/when temporary unmapping makes a comeback, the desirable behavior is
likely to restrict temporary unmapping to vCPU-exclusive mappings and
require the vcpu->mutex be held to serialize unmap. Use of the
refresh_lock to protect unmapping was somewhat specuatively added by
commit 93984f19e7bc ("KVM: Fully serialize gfn=>pfn cache refresh via
mutex") to guard against concurrent unmaps, but the primary use case of
the temporary unmap, nested virtualization[*], doesn't actually need or
want concurrent unmaps.
[*] https://lore.kernel.org/all/20211210163625.2886-7-dwmw2@infradead.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Diffstat (limited to 'mm/userfaultfd.c')
0 files changed, 0 insertions, 0 deletions