On Fri, Aug 28, 2020 at 1:21 PM Alex Williamson <alex.william...@redhat.com> wrote: > > 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.
Yep, makes sense. > > > 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? Do you mean what if we update it to support N IRQs and someone comes around and wants >N IRQs? If this is liable to happen in the future that seems to suggest not emulating any real piece of IOAPIC HW. I guess giving the 82093AA more lines is the kind of thing that could be behind a Kconfig flag for kvm. Not sure if that makes it ok though. It seems like more IRQ lines could be a meaningful improvement to kvm if devices that use legacy interrupts on x86 are here to stay in the long run. As it stands any VMM that wants to emulate a piece of non-PCI hardware that uses interrupts is either out of luck or needs to implement their own IOAPIC in userspace and set up the guest accordingly. > > > 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, Yeah, I'd rather not even look into this since the possibility of coming up with something that works well seems low. Thanks for the responses. I think I'll repost the relevant remaining kvm questions to the kvm mailing list. > > Alex > _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
