[vfio-users] Passing arbitrary IRQ to guest?

Tue Dec 10 23:59:48 UTC 2019

On Mon, 9 Dec 2019 14:18:50 -0800
Micah Morton <mortonm at chromium.org> wrote:

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

So you're asking QEMU to not only pass the ASL to the guest, but parse
it itself to learn about the interrupt objects it might contain, which
it would then setup through vfio.  But then vfio-pci in the kernel
itself needs to become an i2c driver in order to probe the i2c bus
downstream of the PCI endpoint to find these platform devices and then
involve the ACPI subsystem to retrieve the IRQ information for this
downstream device, which then becomes a device specific IRQ on the
exposed PCI endpoint... sure, that's not a hack at all :-\

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

I think if we're going to all the trouble to link things as described
above, you might be better off to teach vfio-platform to understand
i2c, create a virtual i2c bus on the VM, and just assign the i2c device
to the VM.  But then, since you can't do DMA over i2c, this really
sounds more like a UIO driver than a vfio driver.

Anyway, I think the above proposal focuses too much on how we slip an
IRQ into QEMU after the heavy lifting has already been done to make that
IRQ available via vfio, while hand waving that latter bit as non-hacky
and generic.  Thanks,

Alex