On Thu, 27 Aug 2020 17:22:59 -0700 Micah Morton <mort...@chromium.org> wrote:
> Hi Alex/Paolo, > > We talked a few months ago (some of which can be seen here > https://www.spinics.net/lists/kvm/msg217578.html) about adding > platform IRQ forwarding for platform devices behind PCI > controller/adapter devices (for use when the PCI parent device gets > assigned to a VM guest through vfio-pci). Thinking through how it > would work, I've run into the problem that the IOAPIC > (https://pdos.csail.mit.edu/6.828/2018/readings/ia32/ioapic.pdf) that > kvm/QEMU emulate for forwarding platform/PCI interrupts to the guest > is quite limited in terms of free/unused IRQs available for use > (section 2.4 in the ioapic.pdf above gives descriptions). > > I think I'm not the first one to encounter a 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 for what I think is the same > reason: https://www.qemu.org/docs/master/specs/tpm.html#acpi-interface > > A few questions: > 1) Are you aware of anyone ever looking at modernizing the IOAPIC? I > assume this isn't a priority for VFIO since most high > speed/performance HW devices don't use legacy interrupts. I guess it's > not a big issue for kvm/QEMU either since there are not many new > platform devices coming along that people want to emulate for VM > guests (TPM being an exception here). Not only are they typically for "legacy" use cases, but PCI only supports four interrupt lines and these are usually swizzled across the buses to spread out how many devices can share an interrupt. And of course we can generally share interrupts for PCI devices, so it's more of an efficiency, rather than exhaustion issue, so long as the device/driver doesn't require an exclusive interrupt. So no, I don't know any efforts to modernize, it's not a worthwhile limitation for vfio-pci. > 2) If one was to add more IRQs to the IOAPIC would it be a requirement > to find a datasheet from some newer hardware and perfectly emulate > that newer hardware for a more modernized IOAPIC? Or would something > like hacking the 82093AA emulation code to support more than 24 IRQs > be within the realm of possibility? Is it even meaningful for guest > VMs to "think" they're talking to an ancient IOAPIC from 1996? I think that extending an existing real device is potentially problematic. We don't know what dependencies closed source OSes might have or what they'd infer from the device. If you can't find a specific device with widespread support to emulate, maybe it would be possible to implement a generic device. Does this really solve the problem though, or is it just a stopgap? How would we size the ioapic to match the VM hardware configuration? > 3) Was there ever any consideration of making the IOAPIC a > virtio/paravirtualized device rather than an emulated device? Dunno, the qemu-devel and kvm mailing list would be a much more appropriate place to get feedback and history than the vfio-users list. > I figure if there's no reasonable hope of running an x86 VM with > QEMU/kvm with more than 24 IRQ slots then I may look at repurposing > PCI INTx/MSI to forward platform interrupts that come from devices > behind PCI controllers (if the platform IRQ is level triggered use > INTx and edge triggered use MSI). I'm sure that's a whole new can of > worms though. This is sounding like quite a kludge, how does the touchpad i2c device indicate that it interrupts through the assigned PCI i2c controller? Doesn't that controller use interrupts itself? Trying to multiplex the PCI controller interrupt and the i2c device interrupt through INTx sounds messy. You'd also need to mask off MSI/X capabilities on the i2c controller if supported since we can't use INTx and MSI/X at the same time. Thanks, Alex _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
