[vfio-users] Passing arbitrary IRQ to guest?

[Alex Williamson]

On Wed, 31 Jul 2019 09:05:54 -0700
Micah Morton <mortonm at 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