summaryrefslogtreecommitdiffstats
path: root/samples
diff options
context:
space:
mode:
authorSean Christopherson <sean.j.christopherson@intel.com>2019-02-05 22:01:36 +0100
committerPaolo Bonzini <pbonzini@redhat.com>2019-02-20 22:48:48 +0100
commit24efe61f696c7b44a66c7d6a41c181b31aa338fc (patch)
treea5700f18eff710efc0b399e02705b4a8f827b037 /samples
parentKVM: x86/mmu: Differentiate between nr zapped and list unstable (diff)
downloadlinux-24efe61f696c7b44a66c7d6a41c181b31aa338fc.tar.xz
linux-24efe61f696c7b44a66c7d6a41c181b31aa338fc.zip
KVM: x86/mmu: WARN if zapping a MMIO spte results in zapping children
Paolo expressed a concern that kvm_mmu_zap_mmio_sptes() could have a quadratic runtime[1], i.e. restarting the spte walk while zapping only MMIO sptes could result in re-walking large portions of the list over and over due to the non-MMIO sptes encountered before the restart not being removed. At the time, the concern was legitimate as the walk was restarted when any spte was zapped. But that is no longer the case as the walk is now restarted iff one or more children have been zapped, which is necessary because zapping children makes the active_mmu_pages list unstable. Furthermore, it should be impossible for an MMIO spte to have children, i.e. zapping an MMIO spte should never result in zapping children. In other words, kvm_mmu_zap_mmio_sptes() should never restart its walk, and so should always execute in linear time. WARN if this assertion fails. Although it should never be needed, leave the restart logic in place. In normal operation, the cost is at worst an extra CMP+Jcc, and if for some reason the list does become unstable, not restarting would likely crash KVM, or worse, the kernel. [1] https://patchwork.kernel.org/patch/10756589/#22452085 Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'samples')
0 files changed, 0 insertions, 0 deletions