[vfio-users] Passing arbitrary IRQ to guest?

Micah Morton mortonm at chromium.org
Thu Aug 1 04:27:56 UTC 2019


On Wed, Jul 31, 2019 at 3:31 PM Alex Williamson
<alex.williamson at redhat.com> wrote:
>
> 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

Oops, you're exactly right. I forgot to mention that I copied the
block of ACPI source language relating to the i2c touchpad device from
the host DSDT (actually SSDT, but irrelevant) to the guest DSDT by
patching SeaBIOS. This is how the guest driver for hid over i2c
(i2c_hid) knows which IRQ it should be using for the touchpad, among
other things. So I actually have that part working.

> 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

I think this is the only thing on the i2c bus, and even if not I
definitely want to give the whole i2c bus to the guest, so this isn't
a concern.

> 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.

Yeah, I have USB controller passthrough working and those devices work
great in the guest

>
> In checking whether QEMU has i2c passthrough support, I did find this:
>
> https://wiki.qemu.org/Google_Summer_of_Code_2019#I2C_Passthrough

Yeah I've seen this as well:
https://elinux.org/R-Car/I2C-Virtualization but haven't tried any of
the experimental stuff

>
> 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?

Yeah, I followed this guide
https://www.kraxel.org/blog/2016/04/linux-evdev-input-support-in-qemu-2-6/
to get the keyboard evdev interface forwarded, but no luck with the
touchpad. Maybe I can debug that more. Although that link does mention
the touchpad can't be used for evdev forwarding in that person's case
so it might not be feasible.

>
> https://passthroughpo.st/using-evdev-passthrough-seamless-vm-input/
>
> Thanks,
> Alex


I'll have to think more about what you said about "user DMA vs host
DMA". FWIW I'm trying to see how many of the devices on a Chromebook I
can get passed through to a VM. Right now I have GPU, WiFi, USB
controller (so ethernet) PCI passthrough working with evdev keyboard
working as well in the guest. It would be nice to round out this list
with touchpad support if I can get this IRQ stuff worked out. Is it
really that futile to try to forward an IRQ into the guest given the
other background info I've given here? Then again maybe the "user DMA
vs host DMA" issue is a big one and I'm missing that




More information about the vfio-users mailing list