I've recently noticed that the IOAPIC (https://pdos.csail.mit.edu/6.828/2018/readings/ia32/ioapic.pdf) that kvm/QEMU emulate for providing interrupts to a guest VM is quite limited in terms of free/unused IRQs available for use (section 2.4 in the ioapic.pdf above gives descriptions). Essentially there are enough (4) shared PCI IRQ lines to go around for emulated/passthrough PCI devices -- but most/all the other lines have dedicated uses and are unavailable. I see evidence of device emulation code running into this lack of legacy IRQ slots on x86 kvm/QEMU, as here's an example of QEMU's emulated TPM choosing to use polling instead of interrupts since there are no available lines in the IOAPIC: https://www.qemu.org/docs/master/specs/tpm.html#acpi-interface . It seems there are other prospective projects that might run into this issue as well (https://www.mail-archive.com/qemu-devel@xxxxxxxxxx/msg585732.html might be a good example if the i2c devices in question use interrupts -- there may be better examples). From what I can tell, any emulated device someone wants to add to QEMU can’t use interrupts unless it is an emulated PCI device. My particular interest is platform device passthrough on x86 kvm/QEMU/VFIO, which requires legacy IRQ forwarding via the emulated IOAPIC if the platform device uses interrupts. I’m mostly sending this email to see if I am missing any background context on this issue. Has this limitation of the 82093AA IOAPIC been surfaced before in KVM discussions? I recently sent a similar question on the vfio-users mailing list and got a suggestion to use multiple IOAPICs for the guest (https://www.redhat.com/archives/vfio-users/2020-August/msg00038.html). Does this seem like the most reasonable approach? Would it be easy enough to emulate multiple IOAPICs in kvm, assuming the guest OS can handle multiple? Here are a few other possible options: 1) Update the 82093AA emulation to allow for more IRQs (while maintaining backwards compatibility to avoid breaking guests). Of course at this point you are no longer emulating a real piece of hardware. Not sure if there’s any precedent for that. 2) Choose a new IOAPIC HW device to emulate in KVM (that has more IRQs and is widely supported). From what I’ve seen x86 IOAPICs feature >100 IRQ lines these days. 3) Add a virtio/paravirtualized approach for the IOAPIC instead of emulating real hardware for the guest. Any advice on which of these options seems the most reasonable? Thanks, Micah