[vfio-users] DMA Error -14 with I2C controller passthrough

[Alex Williamson]

On Mon, 13 Jan 2020 22:17:29 +0100
Davide Miola <davide.miola99 at gmail.com> wrote:

> Hi,
> 
> I'm trying to passthrough one of the two I2C controllers my laptop has to
> get the touchpad working in a VM (Disclaimer: I know it's not as simple as
> passing through the controller, but I've got to start somewhere).
> 
> I saw this
> <https://www.mail-archive.com/vfio-users@redhat.com/msg03702.html> thread,
> so I think it should be possible after all, but so far I'm facing a lot of
> trouble:
> basically I can't get any of the two I2C controllers of my laptop to
> passthrough, because, after binding them to vfio-pci and starting a VM (I'm
> using a Fedora Workstation iso for that), I get this error:
> 
> qemu-system-x86_64: VFIO_MAP_DMA: -14
> qemu-system-x86_64: vfio_dma_map(0x7f1cccdf0fc0, 0xfebf1000, 0x1000,
> 0x7f1ccf493000) = -14 (Wrong address)
> 
> I get that once when SeaBIOS loads and then another six times in a burst
> when the guest os loads (the amount of times I get that error seems to
> change when using libvirt).
> Dmesg says nothing both on the host and the guest.
> This happens both using libvirt and without, but I've also tried:
>  - 5.4 instead of 5.3 kernel;
>  - Manjaro and Fedora host;
>  - booting in legacy instead of UEFI;
>  - binding to vfio-pci via kernel parameters instead of doing it after boot;
>  - using different QEMU machines;
>  - using OVMF or SeaBIOS;
>  - using KVM or not.
> 
> None of this made any difference.
> 
> I should clarify that that error does not prevent the VM from booting, in
> fact it seems to boot just fine, and lspci on the guest even reports the
> device as being present (same name and vendor/device ids as on the host),
> but it won't bind to intel-lpss, that's the real problem.
> 
> I should also mention that I have no problems passing through other devices
> on this laptop, in fact I've successfully passed through the IGPU (legacy
> passthrough), the USB controller, and chipset audio, all without a problem.
> 
> It goes without saying that I'd be very interested in a possible future
> upstream implementation of something that would allow this kind of
> application, as was proposed in the thread I linked above.
> 
> I have considered using Evdev passthrough, but I find it very unreliable (I
> got it to work for a mouse only via libvirt, keyboard works fine), but I
> just couldn't get it to work for the touchpad: with plain QEMU the touchpad
> kinda works but not as you'd expect, as the mouse teleports to where I
> touch on the touchpad (as if there were a 1:1 mapping between the touchpad
> and the screen), it's very weird and very not usable; and with libvirt I
> couldn't get any mouse movement. But even if I could get it to work, it is
> my understanding that Evdev passthrough just emulates a PS2 mouse, so that
> means I'd lose any multitouch feature, which is not ideal.
> 
> Anyway, my laptop is running a 9th gen CoffeeLake Refresh H-series CPU on
> Manjaro with Linux 5.3 as the main system.

The faulting IOVA (0xfebf1000) looks like it's probably MMIO space of
the device itself, ie. we're trying to establish peer-to-peer DMA
mappings.  This is also the only type of mapping that QEMU would
consider non-fatal to allow the VM to continue running, because they're
rarely used.  I'm curious why this is failing, but I don't think it's
the source of the device not working in the guest.  It looks like the
vfio driver would only generate an -EFAULT for an error in the ioctl
args, so the error might come from deeper in the IOMMU driver in the
host.  Not sure.  Thanks,

Alex