On Wed, 31 Jul 2019 09:05:54 -0700 Micah Morton <mort...@chromium.org> wrote:
> Hi Alex, > > I've noticed that when doing device passthrough with VFIO, if an IRQ > in the host machine is associated with a PCI device that's being > passed to the guest, then the IRQ is automatically forwarded into the > guest by kvm/vfio. Is is possible to tell qemu to forward arbitrary > IRQs to the guest as well? Nope :-\ > My situation is that I am trying to make a touchpad device work in the > VM guest. This device sits behind an i2c controller on the host. When > I pass through the i2c controller (PCI device), its IRQ automatically > gets passed to the guest as well, so everything works on this level. > My problem is that the touchpad device behind the i2c controller is > wired up to use a specific IRQ for interrupts, and since qemu has no > idea this needs to be forwarded along with the i2c controller, it > doesn't get forwarded. Everything else with the i2c controller and > touchpad works as intended in the guest, including aspects of the > touchpad functionality that don't require interrupts. > > I was hoping there was an easy way to tell qemu to forward this IRQ to > the guest (maybe in the same code path where the IRQ for the i2c > controller is forwarded?) -- even though it is not associated with any > PCI device in the host. If not, maybe you could point me to where in > the code I would need to hack to pass an extra IRQ to the guest? Or is > it much more complicated and intractable than I'm making it out to be? Hmm, I think it's actually pretty tricky. The PCI i2c device really just provides you with access to an entirely separate bus. The access to that bus works ok because the interface is fully exposed within the PCI endpoint, but devices on the i2c bus are not. I'd guess there's an ACPI object describing the interrupt for that device, so even if we could transport the IRQ into the VM, you'd likely also need to add an ACPI blob to relay that interrupt association to the device in the guest. I'd also wonder if there are things on the i2c bus that we don't want a user to have access to and whether assigning the full controller to the user is really a wise idea. I'd also expect that the IOMMU can only provide isolation and translation at the PCI requester ID level, so as soon as the IOMMU becomes involved we can't really manage user DMA vs host DMA at the same time. Too bad the touchpad isn't a USB endpoint. In checking whether QEMU has i2c passthrough support, I did find this: https://wiki.qemu.org/Google_Summer_of_Code_2019#I2C_Passthrough I'm not sure if anyone signed up for that, but maybe it includes some breadcrumbs. It seems that your touchpad is really more of a platform device that happens to be exposed via i2c, where the i2c controller happens to live on PCI. That doesn't necessarily make vfio-pci a great target for assignment, you'll only get assignment of the i2c interface and not external dependencies of devices on that i2c bus. A USB passthrough or maybe a vfio mediated device like approach might be a better option, allowing the i2c bus to be owned by a host driver, but exposing specific endpoints to a VM. OTOH, do you really need to expose the i2c device in the guest, or would relaying through the evdev interface be sufficient? https://passthroughpo.st/using-evdev-passthrough-seamless-vm-input/ Thanks, Alex _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
