From 981780cdda5a60ae7ae319933673ff9475245965 Mon Sep 17 00:00:00 2001 From: David Woodhouse Date: Thu, 19 Dec 2024 16:10:30 +0000 Subject: hw/i386/pc: Fix level interrupt sharing for Xen event channel GSI MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The system GSIs are not designed for sharing. One device might assert a shared interrupt with qemu_set_irq() and another might deassert it, and the level from the first device is lost. This could be solved by refactoring the x86 GSI code to use an OrIrq device, but that still wouldn't be ideal. The best answer would be to have a 'resample' callback which is invoked when the interrupt is acked at the interrupt controller, and causes the devices to re-trigger the interrupt if it should still be pending. This is the model that VFIO in Linux uses, with a 'resampler' eventfd that actually unmasks the interrupt on the hardware device and thus triggers a new interrupt from it if needed. As things stand, QEMU currently doesn't use that VFIO interface correctly, and just bashes on the resampler for every MMIO access to the device "just in case". Which requires unmapping and trapping the MMIO while an interrupt is pending! For the Xen callback GSI, QEMU does something similar — a flag is set which triggers a poll on *every* vmexst to see if the GSI should be deasserted. Proper resampler support would solve all of that, but is a task for later which has already been on the TODO list for a while. Since the Xen event channel GSI support *already* has hooks into the PC gsi_handler() code for routing GSIs to PIRQs, we can use that for a simpler bug fix. So... remember the externally-driven state of the line (from e.g. PCI INTx) and set the logical OR of that with the GSI. As a bonus, we now only need to enable the polling of vcpu_info on vmexit if the Xen callback GSI is the *only* reason the corresponding line is asserted. Closes: https://gitlab.com/qemu-project/qemu/-/issues/2731 Fixes: ddf0fd9ae1fd ("hw/xen: Support HVM_PARAM_CALLBACK_TYPE_GSI callback") Reported-by: Thomas Huth Signed-off-by: David Woodhouse Acked-by: Michael S. Tsirkin --- hw/i386/x86-common.c | 32 +++++++++++++++++++++----------- 1 file changed, 21 insertions(+), 11 deletions(-) (limited to 'hw/i386/x86-common.c') diff --git a/hw/i386/x86-common.c b/hw/i386/x86-common.c index a7d46c3105..97b4f7d4a0 100644 --- a/hw/i386/x86-common.c +++ b/hw/i386/x86-common.c @@ -450,8 +450,27 @@ static long get_file_size(FILE *f) void gsi_handler(void *opaque, int n, int level) { GSIState *s = opaque; + bool bypass_ioapic = false; trace_x86_gsi_interrupt(n, level); + +#ifdef CONFIG_XEN_EMU + /* + * Xen delivers the GSI to the Legacy PIC (not that Legacy PIC + * routing actually works properly under Xen). And then to + * *either* the PIRQ handling or the I/OAPIC depending on whether + * the former wants it. + * + * Additionally, this hook allows the Xen event channel GSI to + * work around QEMU's lack of support for shared level interrupts, + * by keeping track of the externally driven state of the pin and + * implementing a logical OR with the state of the evtchn GSI. + */ + if (xen_mode == XEN_EMULATE) { + bypass_ioapic = xen_evtchn_set_gsi(n, &level); + } +#endif + switch (n) { case 0 ... ISA_NUM_IRQS - 1: if (s->i8259_irq[n]) { @@ -460,18 +479,9 @@ void gsi_handler(void *opaque, int n, int level) } /* fall through */ case ISA_NUM_IRQS ... IOAPIC_NUM_PINS - 1: -#ifdef CONFIG_XEN_EMU - /* - * Xen delivers the GSI to the Legacy PIC (not that Legacy PIC - * routing actually works properly under Xen). And then to - * *either* the PIRQ handling or the I/OAPIC depending on - * whether the former wants it. - */ - if (xen_mode == XEN_EMULATE && xen_evtchn_set_gsi(n, level)) { - break; + if (!bypass_ioapic) { + qemu_set_irq(s->ioapic_irq[n], level); } -#endif - qemu_set_irq(s->ioapic_irq[n], level); break; case IO_APIC_SECONDARY_IRQBASE ... IO_APIC_SECONDARY_IRQBASE + IOAPIC_NUM_PINS - 1: -- cgit 1.4.1