summaryrefslogtreecommitdiff
path: root/scripts/generate_rust_analyzer.py
diff options
context:
space:
mode:
authorPrasad Pandit <pjp@fedoraproject.org>2024-01-03 10:53:43 +0300
committerSean Christopherson <seanjc@google.com>2024-01-31 18:35:07 +0300
commit6231c9e1a9f35b535c66709aa8a6eda40dbc4132 (patch)
tree861d45dcf4ab2792e7f67f00aa0513238d2ad856 /scripts/generate_rust_analyzer.py
parent41bccc98fb7931d63d03f326a746ac4d429c1dd3 (diff)
downloadlinux-6231c9e1a9f35b535c66709aa8a6eda40dbc4132.tar.xz
KVM: x86: make KVM_REQ_NMI request iff NMI pending for vcpu
kvm_vcpu_ioctl_x86_set_vcpu_events() routine makes 'KVM_REQ_NMI' request for a vcpu even when its 'events->nmi.pending' is zero. Ex: qemu_thread_start kvm_vcpu_thread_fn qemu_wait_io_event qemu_wait_io_event_common process_queued_cpu_work do_kvm_cpu_synchronize_post_init/_reset kvm_arch_put_registers kvm_put_vcpu_events (cpu, level=[2|3]) This leads vCPU threads in QEMU to constantly acquire & release the global mutex lock, delaying the guest boot due to lock contention. Add check to make KVM_REQ_NMI request only if vcpu has NMI pending. Fixes: bdedff263132 ("KVM: x86: Route pending NMIs from userspace through process_nmi()") Cc: stable@vger.kernel.org Signed-off-by: Prasad Pandit <pjp@fedoraproject.org> Link: https://lore.kernel.org/r/20240103075343.549293-1-ppandit@redhat.com Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'scripts/generate_rust_analyzer.py')
0 files changed, 0 insertions, 0 deletions