[vfio-users] Passing arbitrary IRQ to guest?

[Alex Williamson]

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