[vfio-users] Passing arbitrary IRQ to guest?

[Micah Morton]

On Thu, Sep 5, 2019 at 12:22 PM Micah Morton <mortonm at chromium.org> wrote:
>
> 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,

Hi Alex,

What about the possibility of having some blob of ASL/AML be an input
to qemu, that way one could do something like "qemu-system-x86_64 ...
-device vfio-pci,host=01:00.0,aml-file=/path/to/asl"?

Qemu already has to set up a bunch of ASL for the guest, so this blob
could just be added on as another piece that is passed to the virtual
BIOS, and if there is an "Interrupt" field in the ASL then qemu calls
the VFIO ioctl for setting up IRQ forwarding for the IRQ associated
with the platform device that hangs off of the PCI bus controller. I
believe this solution would avoid needing any device-specific hacks in
VFIO.

Granted, AFAICT this solution is only useful for PCI devices that are
bus controllers (e.g. i2c, SPI, LPC) and have platform devices hanging
off of them, but it can be very simple and useful to pass such devices
to the guest, particularly for latency-sensitive devices like a
touchpad or touchscreen.

Thanks,
Micah

> >
> > Alex
>
> Makes sense, thanks for the explanation!