Re: [vfio-users] Passing arbitrary IRQ to guest?
On Wed, Dec 11, 2019 at 3:09 PM Alex Williamson wrote: > > On Wed, 11 Dec 2019 14:40:56 -0800 > Micah Morton wrote: > > > On Wed, Dec 11, 2019 at 10:44 AM Alex Williamson > > wrote: > > > > > > On Wed, 11 Dec 2019 09:37:57 -0800 > > > Micah Morton wrote: > > > > > > > On Tue, Dec 10, 2019 at 4:00 PM Alex Williamson > > > > wrote: > > > > > > > > > > On Mon, 9 Dec 2019 14:18:50 -0800 > > > > > Micah Morton wrote: > > > > > > > > > > > On Thu, Sep 5, 2019 at 12:22 PM Micah Morton > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Aug 28, 2019 at 3:22 PM Alex Williamson > > > > > > > wrote: > > > > > > > > > > > > > > > > On Wed, 28 Aug 2019 09:39:57 -0700 > > > > > > > > Micah Morton wrote: > > > > > > > > > > > > > > > > > On Mon, Aug 5, 2019 at 11:14 PM Gerd Hoffmann > > > > > > > > > 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 > > > > > > > > > > > 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
Re: [vfio-users] Passing arbitrary IRQ to guest?
On Wed, 11 Dec 2019 14:40:56 -0800 Micah Morton wrote: > On Wed, Dec 11, 2019 at 10:44 AM Alex Williamson > wrote: > > > > On Wed, 11 Dec 2019 09:37:57 -0800 > > Micah Morton wrote: > > > > > On Tue, Dec 10, 2019 at 4:00 PM Alex Williamson > > > wrote: > > > > > > > > On Mon, 9 Dec 2019 14:18:50 -0800 > > > > Micah Morton wrote: > > > > > > > > > On Thu, Sep 5, 2019 at 12:22 PM Micah Morton > > > > > wrote: > > > > > > > > > > > > On Wed, Aug 28, 2019 at 3:22 PM Alex Williamson > > > > > > wrote: > > > > > > > > > > > > > > On Wed, 28 Aug 2019 09:39:57 -0700 > > > > > > > Micah Morton wrote: > > > > > > > > > > > > > > > On Mon, Aug 5, 2019 at 11:14 PM Gerd Hoffmann > > > > > > > > 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 > > > > > > > > > > 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 > > > > > >
Re: [vfio-users] Passing arbitrary IRQ to guest?
On Wed, Dec 11, 2019 at 10:44 AM Alex Williamson wrote: > > On Wed, 11 Dec 2019 09:37:57 -0800 > Micah Morton wrote: > > > On Tue, Dec 10, 2019 at 4:00 PM Alex Williamson > > wrote: > > > > > > On Mon, 9 Dec 2019 14:18:50 -0800 > > > Micah Morton wrote: > > > > > > > On Thu, Sep 5, 2019 at 12:22 PM Micah Morton > > > > wrote: > > > > > > > > > > On Wed, Aug 28, 2019 at 3:22 PM Alex Williamson > > > > > wrote: > > > > > > > > > > > > On Wed, 28 Aug 2019 09:39:57 -0700 > > > > > > Micah Morton wrote: > > > > > > > > > > > > > On Mon, Aug 5, 2019 at 11:14 PM Gerd Hoffmann > > > > > > > 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 > > > > > > > > > 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
Re: [vfio-users] Passing arbitrary IRQ to guest?
On Wed, 11 Dec 2019 09:37:57 -0800 Micah Morton wrote: > On Tue, Dec 10, 2019 at 4:00 PM Alex Williamson > wrote: > > > > On Mon, 9 Dec 2019 14:18:50 -0800 > > Micah Morton wrote: > > > > > On Thu, Sep 5, 2019 at 12:22 PM Micah Morton > > > wrote: > > > > > > > > On Wed, Aug 28, 2019 at 3:22 PM Alex Williamson > > > > wrote: > > > > > > > > > > On Wed, 28 Aug 2019 09:39:57 -0700 > > > > > Micah Morton wrote: > > > > > > > > > > > On Mon, Aug 5, 2019 at 11:14 PM Gerd Hoffmann > > > > > > 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 > > > > > > > > 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
Re: [vfio-users] Passing arbitrary IRQ to guest?
On Tue, Dec 10, 2019 at 4:00 PM Alex Williamson wrote: > > On Mon, 9 Dec 2019 14:18:50 -0800 > Micah Morton wrote: > > > On Thu, Sep 5, 2019 at 12:22 PM Micah Morton wrote: > > > > > > On Wed, Aug 28, 2019 at 3:22 PM Alex Williamson > > > wrote: > > > > > > > > On Wed, 28 Aug 2019 09:39:57 -0700 > > > > Micah Morton wrote: > > > > > > > > > On Mon, Aug 5, 2019 at 11:14 PM Gerd Hoffmann > > > > > 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 > > > > > > > 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
Re: [vfio-users] Passing arbitrary IRQ to guest?
On Thu, Sep 5, 2019 at 12:22 PM Micah Morton wrote: > > On Wed, Aug 28, 2019 at 3:22 PM Alex Williamson > wrote: > > > > On Wed, 28 Aug 2019 09:39:57 -0700 > > Micah Morton wrote: > > > > > On Mon, Aug 5, 2019 at 11:14 PM Gerd Hoffmann 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 > > > > > 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!
Re: [vfio-users] Passing arbitrary IRQ to guest?
On Wed, Aug 28, 2019 at 3:22 PM Alex Williamson wrote: > > On Wed, 28 Aug 2019 09:39:57 -0700 > Micah Morton wrote: > > > On Mon, Aug 5, 2019 at 11:14 PM Gerd Hoffmann 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 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
Re: [vfio-users] Passing arbitrary IRQ to guest?
On Wed, 28 Aug 2019 09:39:57 -0700 Micah Morton wrote: > On Mon, Aug 5, 2019 at 11:14 PM Gerd Hoffmann 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 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 ___ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
Re: [vfio-users] Passing arbitrary IRQ to guest?
On Mon, Aug 5, 2019 at 11:14 PM Gerd Hoffmann 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 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). ___ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
Re: [vfio-users] Passing arbitrary IRQ to guest?
On Mon, Aug 05, 2019 at 12:50:00PM -0700, Micah Morton wrote: > On Thu, Aug 1, 2019 at 10:36 PM Gerd Hoffmann 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 ___ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
Re: [vfio-users] Passing arbitrary IRQ to guest?
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. cheers, Gerd ___ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
Re: [vfio-users] Passing arbitrary IRQ to guest?
On Wed, Jul 31, 2019 at 3:31 PM Alex Williamson wrote: > > On Wed, 31 Jul 2019 09:05:54 -0700 > Micah Morton wrote: > > > Hi Alex, > > > > I've noticed that when doing device passthrough with VFIO, if an IRQ > > in the host machine is associated with a PCI device that's being > > passed to the guest, then the IRQ is automatically forwarded into the > > guest by kvm/vfio. Is is possible to tell qemu to forward arbitrary > > IRQs to the guest as well? > > Nope :-\ > > > My situation is that I am trying to make a touchpad device work in the > > VM guest. This device sits behind an i2c controller on the host. When > > I pass through the i2c controller (PCI device), its IRQ automatically > > gets passed to the guest as well, so everything works on this level. > > My problem is that the touchpad device behind the i2c controller is > > wired up to use a specific IRQ for interrupts, and since qemu has no > > idea this needs to be forwarded along with the i2c controller, it > > doesn't get forwarded. Everything else with the i2c controller and > > touchpad works as intended in the guest, including aspects of the > > touchpad functionality that don't require interrupts. > > > > I was hoping there was an easy way to tell qemu to forward this IRQ to > > the guest (maybe in the same code path where the IRQ for the i2c > > controller is forwarded?) -- even though it is not associated with any > > PCI device in the host. If not, maybe you could point me to where in > > the code I would need to hack to pass an extra IRQ to the guest? Or is > > it much more complicated and intractable than I'm making it out to be? > > Hmm, I think it's actually pretty tricky. The PCI i2c device really > just provides you with access to an entirely separate bus. The access > to that bus works ok because the interface is fully exposed within the > PCI endpoint, but devices on the i2c bus are not. I'd guess there's an > ACPI object describing the interrupt for that device, so even if we > could transport the IRQ into the VM, you'd likely also need to add an > ACPI blob to relay that interrupt association to the device in the > guest. I'd also wonder if there are things on the i2c bus that we Oops, you're exactly right. I forgot to mention that I copied the block of ACPI source language relating to the i2c touchpad device from the host DSDT (actually SSDT, but irrelevant) to the guest DSDT by patching SeaBIOS. This is how the guest driver for hid over i2c (i2c_hid) knows which IRQ it should be using for the touchpad, among other things. So I actually have that part working. > don't want a user to have access to and whether assigning the full > controller to the user is really a wise idea. I'd also expect that the I think this is the only thing on the i2c bus, and even if not I definitely want to give the whole i2c bus to the guest, so this isn't a concern. > IOMMU can only provide isolation and translation at the PCI requester > ID level, so as soon as the IOMMU becomes involved we can't really > manage user DMA vs host DMA at the same time. Too bad the touchpad > isn't a USB endpoint. Yeah, I have USB controller passthrough working and those devices work great in the guest > > In checking whether QEMU has i2c passthrough support, I did find this: > > https://wiki.qemu.org/Google_Summer_of_Code_2019#I2C_Passthrough Yeah I've seen this as well: https://elinux.org/R-Car/I2C-Virtualization but haven't tried any of the experimental stuff > > I'm not sure if anyone signed up for that, but maybe it includes some > breadcrumbs. > > It seems that your touchpad is really more of a platform device that > happens to be exposed via i2c, where the i2c controller happens to live > on PCI. That doesn't necessarily make vfio-pci a great target for > assignment, you'll only get assignment of the i2c interface and not > external dependencies of devices on that i2c bus. A USB passthrough or > maybe a vfio mediated device like approach might be a better option, > allowing the i2c bus to be owned by a host driver, but exposing > specific endpoints to a VM. > > OTOH, do you really need to expose the i2c device in the guest, or > would relaying through the evdev interface be sufficient? Yeah, I followed this guide https://www.kraxel.org/blog/2016/04/linux-evdev-input-support-in-qemu-2-6/ to get the keyboard evdev interface forwarded, but no luck with the touchpad. Maybe I can debug that more. Although that link does mention the touchpad can't be used for evdev forwarding in that person's case so it might not be feasible. > > https://passthroughpo.st/using-evdev-passthrough-seamless-vm-input/ > > Thanks, > Alex I'll have to think more about what you said about "user DMA vs host DMA". FWIW I'm trying to see how many of the devices on a Chromebook I can get passed through to a VM. Right now I have GPU, WiFi, USB controller (so ethernet) PCI passthrough working with evdev keyboard working as well in the guest. It would be nice to round out this
Re: [vfio-users] Passing arbitrary IRQ to guest?
On Wed, 31 Jul 2019 09:05:54 -0700 Micah Morton wrote: > Hi Alex, > > I've noticed that when doing device passthrough with VFIO, if an IRQ > in the host machine is associated with a PCI device that's being > passed to the guest, then the IRQ is automatically forwarded into the > guest by kvm/vfio. Is is possible to tell qemu to forward arbitrary > IRQs to the guest as well? Nope :-\ > My situation is that I am trying to make a touchpad device work in the > VM guest. This device sits behind an i2c controller on the host. When > I pass through the i2c controller (PCI device), its IRQ automatically > gets passed to the guest as well, so everything works on this level. > My problem is that the touchpad device behind the i2c controller is > wired up to use a specific IRQ for interrupts, and since qemu has no > idea this needs to be forwarded along with the i2c controller, it > doesn't get forwarded. Everything else with the i2c controller and > touchpad works as intended in the guest, including aspects of the > touchpad functionality that don't require interrupts. > > I was hoping there was an easy way to tell qemu to forward this IRQ to > the guest (maybe in the same code path where the IRQ for the i2c > controller is forwarded?) -- even though it is not associated with any > PCI device in the host. If not, maybe you could point me to where in > the code I would need to hack to pass an extra IRQ to the guest? Or is > it much more complicated and intractable than I'm making it out to be? Hmm, I think it's actually pretty tricky. The PCI i2c device really just provides you with access to an entirely separate bus. The access to that bus works ok because the interface is fully exposed within the PCI endpoint, but devices on the i2c bus are not. I'd guess there's an ACPI object describing the interrupt for that device, so even if we could transport the IRQ into the VM, you'd likely also need to add an ACPI blob to relay that interrupt association to the device in the guest. I'd also wonder if there are things on the i2c bus that we don't want a user to have access to and whether assigning the full controller to the user is really a wise idea. I'd also expect that the IOMMU can only provide isolation and translation at the PCI requester ID level, so as soon as the IOMMU becomes involved we can't really manage user DMA vs host DMA at the same time. Too bad the touchpad isn't a USB endpoint. In checking whether QEMU has i2c passthrough support, I did find this: https://wiki.qemu.org/Google_Summer_of_Code_2019#I2C_Passthrough I'm not sure if anyone signed up for that, but maybe it includes some breadcrumbs. It seems that your touchpad is really more of a platform device that happens to be exposed via i2c, where the i2c controller happens to live on PCI. That doesn't necessarily make vfio-pci a great target for assignment, you'll only get assignment of the i2c interface and not external dependencies of devices on that i2c bus. A USB passthrough or maybe a vfio mediated device like approach might be a better option, allowing the i2c bus to be owned by a host driver, but exposing specific endpoints to a VM. OTOH, do you really need to expose the i2c device in the guest, or would relaying through the evdev interface be sufficient? https://passthroughpo.st/using-evdev-passthrough-seamless-vm-input/ Thanks, Alex ___ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
[vfio-users] Passing arbitrary IRQ to guest?
Hi Alex, I've noticed that when doing device passthrough with VFIO, if an IRQ in the host machine is associated with a PCI device that's being passed to the guest, then the IRQ is automatically forwarded into the guest by kvm/vfio. Is is possible to tell qemu to forward arbitrary IRQs to the guest as well? My situation is that I am trying to make a touchpad device work in the VM guest. This device sits behind an i2c controller on the host. When I pass through the i2c controller (PCI device), its IRQ automatically gets passed to the guest as well, so everything works on this level. My problem is that the touchpad device behind the i2c controller is wired up to use a specific IRQ for interrupts, and since qemu has no idea this needs to be forwarded along with the i2c controller, it doesn't get forwarded. Everything else with the i2c controller and touchpad works as intended in the guest, including aspects of the touchpad functionality that don't require interrupts. I was hoping there was an easy way to tell qemu to forward this IRQ to the guest (maybe in the same code path where the IRQ for the i2c controller is forwarded?) -- even though it is not associated with any PCI device in the host. If not, maybe you could point me to where in the code I would need to hack to pass an extra IRQ to the guest? Or is it much more complicated and intractable than I'm making it out to be? Thanks! P.S. I've seen a couple threads you're on that are related, but don't totally answer my question: [1] https://www.redhat.com/archives/vfio-users/2017-October/msg00019.html [2] https://stackoverflow.com/questions/29461518/interrupt-handling-for-assigned-device-through-vfio ___ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
