[vfio-users] Passing arbitrary IRQ to guest?

Thu Aug 1 21:29:40 UTC 2019

On Thu, Aug 1, 2019 at 10:18 AM Alex Williamson
<alex.williamson at redhat.com> wrote:
>
> On Wed, 31 Jul 2019 21:27:56 -0700
> Micah Morton <mortonm at chromium.org> wrote:
>
> > 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
>
> The vfio API provides mechanisms by which we can describe device
> specific IRQs, but how does a PCI meta driver know that the device it's
> bound to has this external interrupt associated through the PCI
> endpoint?  And how do we automatically push that association up through
> the API to avoid custom ACPI blobs?  The vfio-platform driver has this
> sort of issue with "platform" devices, which is more or less what this
> touchpad seems to be, but I think they only solve the problem with
> device tree, not ACPI.

Yeah, I wasn't meaning to suggest that this was a problem that should
be solved by vfio-pci, I was just looking for a pointer to the
qemu/vfio code that handles the IRQ stuff so I could get a better
understanding at whats going on there. Maybe this is a good place to
start: https://elixir.bootlin.com/linux/latest/source/drivers/vfio/platform/vfio_platform_irq.c
. Seems like if the host firmware needs to tell the OS about a device
through ACPI tables then that probably needs to happen in the virtual
firmware as well. And vfio-pci probably shouldn't be telling the guest
about IRQs that are used by devices behind controllers that happen to
live on the PCI bus, but maybe it can be done outside of vfio-pci.
CC'ing Antonios Motakis to see if he has any insight on the IRQ stuff.

>
> The idea behind vfio-pci is that to the extent possible, we don't know
> any specifics of the device, we just expose the PCI interface, where
> this interrupt lives outside of that space.  We've been known to break
> that model in some cases, for things like IGD, which also has some
> external dependencies.  I'm not sure what those sort of extensions look
> like here though.  Can we detect via PCI class code that a device is an
> i2c controller?  Do we really want/need to add i2c enumeration into the
> vfio-pci driver?  How do we determine and expose the ACPI association?

Yeah, it seems awkward to do these things with vfio-pci.

>
> From my perspective, as a low-speed device where we don't really need
> the benefits of an IOMMU, I'd be more inclined to look at why it
> doesn't work with evdev.  We already have a tablet device in QEMU,
> what's it take to connect that to evdev?  Cc'ing Gerd as maybe he's
> already though about touchpad support.  Thanks,

Good idea, thanks

>
> Alex