summaryrefslogtreecommitdiffstats
path: root/rust/bindings
diff options
context:
space:
mode:
authorSean Christopherson <seanjc@google.com>2024-01-09 16:39:35 -0800
committerSean Christopherson <seanjc@google.com>2024-02-22 16:26:26 -0800
commit77bcd9e6231a5297ef417a7d7f734d61c2bcceb6 (patch)
treecab40abfd19ea43db33e84549d7588a6febd0623 /rust/bindings
parentfc3c94142b3a4391cab94adde56fcfbea25723e5 (diff)
downloadlinux-stable-77bcd9e6231a5297ef417a7d7f734d61c2bcceb6.tar.gz
linux-stable-77bcd9e6231a5297ef417a7d7f734d61c2bcceb6.tar.bz2
linux-stable-77bcd9e6231a5297ef417a7d7f734d61c2bcceb6.zip
KVM: Add dedicated arch hook for querying if vCPU was preempted in-kernel
Plumb in a dedicated hook for querying whether or not a vCPU was preempted in-kernel. Unlike literally every other architecture, x86's VMX can check if a vCPU is in kernel context if and only if the vCPU is loaded on the current pCPU. x86's kvm_arch_vcpu_in_kernel() works around the limitation by querying kvm_get_running_vcpu() and redirecting to vcpu->arch.preempted_in_kernel as needed. But that's unnecessary, confusing, and fragile, e.g. x86 has had at least one bug where KVM incorrectly used a stale preempted_in_kernel. No functional change intended. Reviewed-by: Yuan Yao <yuan.yao@intel.com> Link: https://lore.kernel.org/r/20240110003938.490206-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'rust/bindings')
0 files changed, 0 insertions, 0 deletions