summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin/stackcollapse-report
diff options
context:
space:
mode:
authorSean Christopherson <seanjc@google.com>2026-09-02 14:17:59 -0700
committerSean Christopherson <seanjc@google.com>2026-09-11 12:01:51 -0700
commitdf269c8e097f306b09d9f371a60a936e2530c10d (patch)
tree237af250e851c5b54f1bf0d52df4d80136debc9f /tools/perf/scripts/python/bin/stackcollapse-report
parentf7a3be22761953f4a1f754786b7a35b4c5ea6824 (diff)
KVM: x86/mmu: Always guard rmaps with mmu_lock on PREEMPT_RT=y kernels
For all intents and purposes, revert KVM's ability to walk rmaps outside of mmu_lock when running on a realtime (PREEMPT_RT=y) kernel. I.e. don't use a non-sleepable bit-spinlock to protect rmap entries, as realtime kernels are highly unlikely to benefit from increased aging throughput and reduced jitter for memory-overcommitted nested VMs, whereas using a non-sleepable lock is currently buggy and goes against the spirit of realtime kernels. Because KVM's rmap locks are hand-crafted bit-spinlocks, preemption must be disabled before acquiring the lock, otherwise a preempted lock holder will result in all other walkers of the locked rmap to spin and wait, with no tracked owner for PI to boost. For non-RT kernels, acquiring mmu_lock suffices, as mmu_lock is a non-sleepable rwlock. But on RT, where mmu_lock becomes sleepable, preemption is left enabled for rmap writers: WARNING: arch/x86/kvm/mmu/mmu.c:920 at __kvm_rmap_lock+0x1a7/0x1e0 [kvm], CPU#16: vmx_apic_update/3708 CPU: 16 UID: 0 PID: 3708 Comm: vmx_apic_update Not tainted 7.2.0-rc7 #52 PREEMPT_{RT,LAZY} RIP: 0010:__kvm_rmap_lock+0x1a7/0x1e0 [kvm] Call Trace: pte_list_add+0x67/0x4d0 [kvm] __link_shadow_page+0x249/0x480 [kvm] ept_fetch+0x4d5/0x1220 [kvm] ept_page_fault+0x60b/0x850 [kvm] kvm_mmu_do_page_fault+0x252/0x690 [kvm] Alternatively, KVM could manually disable preemption when grabbing an rmap lock, but as above, that isn't what RT kernels generally want, and it's actually more complex to implement (cleanly). To not completely lose the scaling advantage of per-rmap locks, take mmu_lock for read in the aging path, i.e. allow multiple concurrent aging tasks, as the aging code needs to use atomic SPTE accesses no matter what, i.e. no extra code/work is required to guard against concurrent aging of SPTEs. Reported-by: David Woodhouse <dwmw2@infradead.org> Closes: https://lore.kernel.org/all/8d47b43e1829ac92703723e6a1a4afc7a2eaacb5.camel@infradead.org Fixes: 4834eaded91e ("KVM: x86/mmu: Add infrastructure to allow walking rmaps outside of mmu_lock") Reviewed-by: David Woodhouse <dwmw@amazon.co.uk> Tested-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: James Houghton <jthoughton@google.com> Link: https://patch.msgid.link/20260902211759.2700289-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-report')
0 files changed, 0 insertions, 0 deletions