]> www.infradead.org Git - users/dwmw2/linux.git/commit
KVM: pfncache: Implement range-based invalidation check for hva_to_pfn_retry()
authorDavid Woodhouse <dwmw@amazon.co.uk>
Wed, 21 Aug 2024 19:08:17 +0000 (20:08 +0100)
committerDavid Woodhouse <dwmw@amazon.co.uk>
Wed, 21 Aug 2024 19:59:41 +0000 (20:59 +0100)
commit723f68f4159623c83e14dc5a557298fd7c776158
tree4b633c5bd1b0d9006d0f4c08fea6620f50e1e0e2
parentf1f7371af9ffae59ec9bf43792facb3b7393c5e0
KVM: pfncache: Implement range-based invalidation check for hva_to_pfn_retry()

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. In
addition to the ->needs_invalidation flag added in a previous commit,
check before calling hva_to_pfn() if there is any pending invalidation
(i.e. between invalidate_range_start() and invalidate_range_end()) which
affects the uHVA of the GPC being updated. This catches the case where
hva_to_pfn() would return a soon-to-be-stale mapping of a range for which
the invalidate_range_start() hook had already been called before the uHVA
was even set in the GPC and the ->needs_invalidation flag set.

An invalidation which *starts* after the lock is dropped in the loop is
fine because it will clear the ->needs_revalidation flag and also trigger
a retry.

This is slightly more complex than it needs to be; moving the
invalidation to occur in the invalidate_range_end() hook will make life
simpler, in a subsequent commit.

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