diff options
author | Sean Christopherson <seanjc@google.com> | 2023-06-02 04:15:16 +0300 |
---|---|---|
committer | Sean Christopherson <seanjc@google.com> | 2023-06-07 01:07:04 +0300 |
commit | 878940b33d7678e39a526ffe264ee025977dc67e (patch) | |
tree | f6fbd29215bfeed32a924ea16f46f154d84e6a39 /virt/kvm | |
parent | c3a1e119a343a70a9f49689b8f18bb43f236d681 (diff) | |
download | linux-878940b33d7678e39a526ffe264ee025977dc67e.tar.xz |
KVM: VMX: Retry APIC-access page reload if invalidation is in-progress
Re-request an APIC-access page reload if there is a relevant mmu_notifier
invalidation in-progress when KVM retrieves the backing pfn, i.e. stall
vCPUs until the backing pfn for the APIC-access page is "officially"
stable. Relying on the primary MMU to not make changes after invoking
->invalidate_range() works, e.g. any additional changes to a PRESENT PTE
would also trigger an ->invalidate_range(), but using ->invalidate_range()
to fudge around KVM not honoring past and in-progress invalidations is a
bit hacky.
Honoring invalidations will allow using KVM's standard mmu_notifier hooks
to detect APIC-access page reloads, which will in turn allow removing
KVM's implementation of ->invalidate_range() (the APIC-access page case is
a true one-off).
Opportunistically add a comment to explain why doing nothing if a memslot
isn't found is functionally correct.
Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
Cc: Alistair Popple <apopple@nvidia.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Alistair Popple <apopple@nvidia.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Link: https://lore.kernel.org/r/20230602011518.787006-2-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'virt/kvm')
0 files changed, 0 insertions, 0 deletions