[vfio-users] Passing arbitrary IRQ to guest?

[Micah Morton]

On Wed, Aug 28, 2019 at 3:22 PM Alex Williamson
<alex.williamson at redhat.com> wrote:
>
> On Wed, 28 Aug 2019 09:39:57 -0700
> Micah Morton <mortonm at chromium.org> wrote:
>
> > On Mon, Aug 5, 2019 at 11:14 PM Gerd Hoffmann <kraxel at redhat.com> wrote:
> > >
> > > On Mon, Aug 05, 2019 at 12:50:00PM -0700, Micah Morton wrote:
> > > > On Thu, Aug 1, 2019 at 10:36 PM Gerd Hoffmann <kraxel at redhat.com> wrote:
> > > > >
> > > > >   Hi,
> > > > >
> > > > > > 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,
> > > > >
> > > > > It's not clear why the touchpad doesn't work.  Possibly using libinput
> > > > > helps, https://git.kraxel.org/cgit/qemu/log/?h=sirius/display-drm has
> > > > > some code.  Wiring up to input-linux isn't done yet though, only the
> > > > > drm ui uses libinput support so far.
> > > >
> > > > To be clear are you saying that its a known issue that the touchpad
> > > > doesn't work in VM guest with QEMU and evdev?
> > >
> > > There are other reports of touchpad problems.  I don't know whenever
> > > that is a general problem or specific to some devices.
> > >
> > > libinput knows quirks for lots of input devices.  When passing through
> > > the evdev to the guest as virtio device libinput can't see the device
> > > identity and thus can't apply quirks.  Which might be the reason the
> > > touchpad doesn't work.  Using libinput on the host side might fix this.
> > >
> > > cheers,
> > >   Gerd
> > >
> >
> > I was able to get physical passthrough of the touchpad working in the
> > VM guest by forwarding the IRQ to the guest using the kvm/qemu/vfio
> > framework.
> >
> > So basically I wrote extensions to kvm/qemu/vfio to allow for
> > forwarding arbitrary IRQs to the guest (the IRQ doesn't have to be
> > associated with any vfio-pci or vfio-platform device). I could clean
> > up the patches and upstream them (or think about it) if you folks
> > think anyone else might want to use this functionality? Then again as
> > Alex said before you still need to communicate to the VM which IRQ to
> > use for this device (in my case I did this by modifying ACPI stuff in
> > SeaBIOS, not sure how it could be incorporated into vfio).
>
> This seems like something that's not too difficult to hack together,
> but quite a lot harder to generalize into something that's useful
> beyond this specific hardware.  There's a path to do so via the vfio
> API, using a device specific interrupt to expose this IRQ and a
> capability to convey how that IRQ is associated so that QEMU could
> automatically create some AML.  Defining that interaction is far from

Yeah, seems like the user being willing to modify the virtual bios to
add AML info is a pretty fringe use case.

> trivial, but before we even approach that, how does vfio-pci learn to
> associate this IRQ with a device without growing a full software stack
> specific to the PCI device, or class of PCI devices?  We have some

I guess I was envisioning a command line argument to qemu, something
like `-device vfio-pci,host=00:0X.0,irq-passthrough=X`. Then again the
command line would at least need to specify level vs edge triggered I
think, and maybe other things I haven't thought of (in addition to
telling the guest these things through AML).

> hacks in vfio, but they're usually for devices that can work on any
> system, not specific devices on specific systems.  I wouldn't be
> willing to support that unless it's at least got some obvious
> extensibility to work elsewhere.  Thanks,
>
> Alex

Makes sense, thanks for the explanation!