On Wed, Aug 28, 2019 at 3:22 PM Alex Williamson <alex.william...@redhat.com> wrote: > > On Wed, 28 Aug 2019 09:39:57 -0700 > Micah Morton <mort...@chromium.org> wrote: > > > On Mon, Aug 5, 2019 at 11:14 PM Gerd Hoffmann <kra...@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 <kra...@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! _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users