diff options
| author | Sean Christopherson <seanjc@google.com> | 2025-08-05 12:05:14 -0700 |
|---|---|---|
| committer | Sean Christopherson <seanjc@google.com> | 2025-08-19 11:59:34 -0700 |
| commit | aebcbb60977323c21c8d89eb4298e454f8e89299 (patch) | |
| tree | da4e5811be7ac8e81675d33031c042326d04de42 /scripts/bpf_doc.py | |
| parent | 0a94b2042419f7896f5d362465731506e43bc319 (diff) | |
KVM: x86: Acquire SRCU in WRMSR fastpath iff instruction needs to be skipped
Acquire SRCU in the WRMSR fastpath if and only if an instruction needs to
be skipped, i.e. only if the fastpath succeeds. The reasoning in commit
3f2739bd1e0b ("KVM: x86: Acquire SRCU read lock when handling fastpath MSR
writes") about "avoid having to play whack-a-mole" seems sound, but in
hindsight unconditionally acquiring SRCU does more harm than good.
While acquiring/releasing SRCU isn't slow per se, the things that are
_protected_ by kvm->srcu are generally safe to access only in the "slow"
VM-Exit path. E.g. accessing memslots in generic helpers is never safe,
because accessing guest memory with IRQs disabled is unless unsafe (except
when kvm_vcpu_read_guest_atomic() is used, but that API should never be
used in emulation helpers).
In other words, playing whack-a-mole is actually desirable in this case,
because every access to an asset protected by kvm->srcu warrants further
scrutiny.
Link: https://lore.kernel.org/r/20250805190526.1453366-7-seanjc@google.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'scripts/bpf_doc.py')
0 files changed, 0 insertions, 0 deletions
