summaryrefslogtreecommitdiffstats
path: root/mm/userfaultfd.c
diff options
context:
space:
mode:
authorSean Christopherson <seanjc@google.com>2022-10-13 21:12:29 +0000
committerDavid Woodhouse <dwmw@amazon.co.uk>2022-11-30 19:25:24 +0000
commit9f87791d686d85614584438d4f249eb32ef7964c (patch)
treec2c4a01fd11883c843242ad0a3035fd7754809fa /mm/userfaultfd.c
parent0318f207d1c2e297d1ec1c6e145bb8bd053236f9 (diff)
downloadlinux-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