Not enough IRQ lines on the 82093AA IOAPIC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux