summaryrefslogtreecommitdiff
path: root/tools/docs/parse-headers.py
diff options
context:
space:
mode:
authorSean Christopherson <seanjc@google.com>2025-08-05 22:05:25 +0300
committerSean Christopherson <seanjc@google.com>2025-08-19 21:59:42 +0300
commit8bb8b60c95c55c13f9924f3f090232e14d035d43 (patch)
tree1287e1b9a388eab3a8284d227491635cef88d63a /tools/docs/parse-headers.py
parent3eced8b07bb984a3bd2959f0644c14929c848c3b (diff)
downloadlinux-8bb8b60c95c55c13f9924f3f090232e14d035d43.tar.xz
KVM: x86: Push acquisition of SRCU in fastpath into kvm_pmu_trigger_event()
Acquire SRCU in the VM-Exit fastpath if and only if KVM needs to check the PMU event filter, to further trim the amount of code that is executed with SRCU protection in the fastpath. Counter-intuitively, holding SRCU can do more harm than good due to masking potential bugs, and introducing a new SRCU-protected asset to code reachable via kvm_skip_emulated_instruction() would be quite notable, i.e. definitely worth auditing. E.g. the primary user of kvm->srcu is KVM's memslots, accessing memslots all but guarantees guest memory may be accessed, accessing guest memory can fault, and page faults might sleep, which isn't allowed while IRQs are disabled. Not acquiring SRCU means the (hypothetical) illegal sleep would be flagged when running with PROVE_RCU=y, even if DEBUG_ATOMIC_SLEEP=n. Note, performance is NOT a motivating factor, as SRCU lock/unlock only adds ~15 cycles of latency to fastpath VM-Exits. I.e. overhead isn't a concern _if_ SRCU protection needs to be extended beyond PMU events, e.g. to honor userspace MSR filters. Reviewed-by: Dapeng Mi <dapeng1.mi@linux.intel.com> Link: https://lore.kernel.org/r/20250805190526.1453366-18-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'tools/docs/parse-headers.py')
0 files changed, 0 insertions, 0 deletions