diff options
author | Sean Christopherson <seanjc@google.com> | 2022-11-11 00:18:41 +0000 |
---|---|---|
committer | Paolo Bonzini <pbonzini@redhat.com> | 2022-11-11 07:19:46 -0500 |
commit | 6d3085e4d89ad7e6c7f1c6cf929d903393565861 (patch) | |
tree | c777842fc7f1aab49ac04b147a737475ab0d2718 /virt/kvm/kvm_main.c | |
parent | d72cf8ffe460824fdc97f0a9295a2c4e0231a562 (diff) | |
download | linux-6d3085e4d89ad7e6c7f1c6cf929d903393565861.tar.gz linux-6d3085e4d89ad7e6c7f1c6cf929d903393565861.tar.bz2 linux-6d3085e4d89ad7e6c7f1c6cf929d903393565861.zip |
KVM: x86/mmu: Block all page faults during kvm_zap_gfn_range()
When zapping a GFN range, pass 0 => ALL_ONES for the to-be-invalidated
range to effectively block all page faults while the zap is in-progress.
The invalidation helpers take a host virtual address, whereas zapping a
GFN obviously provides a guest physical address and with the wrong unit
of measurement (frame vs. byte).
Alternatively, KVM could walk all memslots to get the associated HVAs,
but thanks to SMM, that would require multiple lookups. And practically
speaking, kvm_zap_gfn_range() usage is quite rare and not a hot path,
e.g. MTRR and CR0.CD are almost guaranteed to be done only on vCPU0
during boot, and APICv inhibits are similarly infrequent operations.
Fixes: edb298c663fc ("KVM: x86/mmu: bump mmu notifier count in kvm_zap_gfn_range")
Reported-by: Chao Peng <chao.p.peng@linux.intel.com>
Cc: stable@vger.kernel.org
Cc: Maxim Levitsky <mlevitsk@redhat.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20221111001841.2412598-1-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'virt/kvm/kvm_main.c')
0 files changed, 0 insertions, 0 deletions