]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
KVM: x86: Acquire SRCU in WRMSR fastpath iff instruction needs to be skipped
authorSean Christopherson <seanjc@google.com>
Tue, 5 Aug 2025 19:05:14 +0000 (12:05 -0700)
committerSean Christopherson <seanjc@google.com>
Tue, 19 Aug 2025 18:59:34 +0000 (11:59 -0700)
commitaebcbb60977323c21c8d89eb4298e454f8e89299
treeda4e5811be7ac8e81675d33031c042326d04de42
parent0a94b2042419f7896f5d362465731506e43bc319
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>
arch/x86/kvm/x86.c