summaryrefslogtreecommitdiffstats
path: root/virt
diff options
context:
space:
mode:
authorDavid Woodhouse <dwmw@amazon.co.uk>2024-02-27 11:49:16 +0000
committerSean Christopherson <seanjc@google.com>2024-03-04 16:22:36 -0800
commit8e62bf2bfa46367e14d0ffdcde5aada08759497c (patch)
tree8a7487f98b6c8ec56bfe4ce4d507848017abae5f /virt
parent451a707813aee24b4a734f28d1d414be0360862b (diff)
downloadlinux-8e62bf2bfa46367e14d0ffdcde5aada08759497c.tar.gz
linux-8e62bf2bfa46367e14d0ffdcde5aada08759497c.tar.bz2
linux-8e62bf2bfa46367e14d0ffdcde5aada08759497c.zip
KVM: x86/xen: inject vCPU upcall vector when local APIC is enabled
Linux guests since commit b1c3497e604d ("x86/xen: Add support for HVMOP_set_evtchn_upcall_vector") in v6.0 onwards will use the per-vCPU upcall vector when it's advertised in the Xen CPUID leaves. This upcall is injected through the guest's local APIC as an MSI, unlike the older system vector which was merely injected by the hypervisor any time the CPU was able to receive an interrupt and the upcall_pending flags is set in its vcpu_info. Effectively, that makes the per-CPU upcall edge triggered instead of level triggered, which results in the upcall being lost if the MSI is delivered when the local APIC is *disabled*. Xen checks the vcpu_info->evtchn_upcall_pending flag when the local APIC for a vCPU is software enabled (in fact, on any write to the SPIV register which doesn't disable the APIC). Do the same in KVM since KVM doesn't provide a way for userspace to intervene and trap accesses to the SPIV register of a local APIC emulated by KVM. Fixes: fde0451be8fb3 ("KVM: x86/xen: Support per-vCPU event channel upcall via local APIC") Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Reviewed-by: Paul Durrant <paul@xen.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20240227115648.3104-3-dwmw2@infradead.org Signed-off-by: Sean Christopherson <seanjc@google.com>
Diffstat (limited to 'virt')
0 files changed, 0 insertions, 0 deletions