]> www.infradead.org Git - users/dwmw2/linux.git/commit
KVM: Move gfn_to_pfn_cache invalidation to invalidate_range_end hook
authorDavid Woodhouse <dwmw@amazon.co.uk>
Fri, 2 Aug 2024 23:03:41 +0000 (00:03 +0100)
committerDavid Woodhouse <dwmw@amazon.co.uk>
Tue, 20 Aug 2024 19:48:42 +0000 (20:48 +0100)
commitba5c20a60eaf2ea2fc6f6fbf6d72e67b8bc2eef3
tree4dd2394d88e91fb90f39e6c240ebb1f2642a3449
parent15e1c3d65975524c5c792fcd59f7d89f00402261
KVM: Move gfn_to_pfn_cache invalidation to invalidate_range_end hook

The existing retry loop in hva_to_pfn_retry() is extremely pessimistic.
If there are any concurrent invalidations running, it's effectively just
a complex busy wait loop because its local mmu_notifier_retry_cache()
function will always return true.

Since multiple invalidations can be running in parallel, this can result
in a situation where hva_to_pfn_retry() just backs off and keep retrying
for ever, not making any progress.

Solve this by being a bit more selective about when to retry.

Introduce a separate 'needs invalidation' flag to the GPC, which allows
it to be marked invalid even while hva_to_pfn_retry() has dropped the
lock to map the newly-found PFN. This allows the invalidation to moved
to the range_end hook, and the retry loop only occurs for a given GPC if
its particular uHVA is affected.

However, the contract for invalidate_range_{start,end} is not like a
simple TLB; the pages may have been freed by the time the end hook is
called. A "device" may not create new mappings after the _start_ hook is
called. To meet this requirement, hva_to_pfn_retry() now waits until no
invalidations are currently running which may affect its uHVA, before
finally setting the ->valid flag and returning.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
include/linux/kvm_host.h
include/linux/kvm_types.h
virt/kvm/kvm_main.c
virt/kvm/kvm_mm.h
virt/kvm/pfncache.c