mirror of
https://github.com/Motorhead1991/qemu.git
synced 2025-08-02 23:33:54 -06:00
![]() A guest which has configured the per-vCPU upcall vector may set the
HVM_PARAM_CALLBACK_IRQ param to fairly much anything other than zero.
For example, Linux v6.0+ after commit b1c3497e604 ("x86/xen: Add support
for HVMOP_set_evtchn_upcall_vector") will just do this after setting the
vector:
/* Trick toolstack to think we are enlightened. */
if (!cpu)
rc = xen_set_callback_via(1);
That's explicitly setting the delivery to GSI#1, but it's supposed to be
overridden by the per-vCPU vector setting. This mostly works in Qemu
*except* for the logic to enable the in-kernel handling of event channels,
which falsely determines that the kernel cannot accelerate GSI delivery
in this case.
Add a kvm_xen_has_vcpu_callback_vector() to report whether vCPU#0 has
the vector set, and use that in xen_evtchn_set_callback_param() to
enable the kernel acceleration features even when the param *appears*
to be set to target a GSI.
Preserve the Xen behaviour that when HVM_PARAM_CALLBACK_IRQ is set to
*zero* the event channel delivery is disabled completely. (Which is
what that bizarre guest behaviour is working round in the first place.)
Cc: qemu-stable@nongnu.org
Fixes:
|
||
---|---|---|
.. | ||
kvm | ||
xen | ||
acpi-build.c | ||
acpi-build.h | ||
acpi-common.c | ||
acpi-common.h | ||
acpi-microvm.c | ||
acpi-microvm.h | ||
amd_iommu.c | ||
amd_iommu.h | ||
e820_memory_layout.c | ||
e820_memory_layout.h | ||
fw_cfg.c | ||
fw_cfg.h | ||
intel_iommu.c | ||
intel_iommu_internal.h | ||
Kconfig | ||
kvmvapic.c | ||
meson.build | ||
microvm-dt.c | ||
microvm-dt.h | ||
microvm.c | ||
multiboot.c | ||
multiboot.h | ||
pc.c | ||
pc_piix.c | ||
pc_q35.c | ||
pc_sysfw.c | ||
pc_sysfw_ovmf-stubs.c | ||
pc_sysfw_ovmf.c | ||
port92.c | ||
sgx-epc.c | ||
sgx-stub.c | ||
sgx.c | ||
trace-events | ||
trace.h | ||
vmmouse.c | ||
vmport.c | ||
x86-iommu-stub.c | ||
x86-iommu.c | ||
x86.c |