<div dir="ltr">Hi,<div><br></div><div>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).</div><div><br></div><div>I saw <a href="https://www.mail-archive.com/vfio-users@redhat.com/msg03702.html">this</a> thread, so I think it should be possible after all, but so far I'm facing a lot of trouble:</div><div>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:</div><div><br></div><div>qemu-system-x86_64: VFIO_MAP_DMA: -14<br>qemu-system-x86_64: vfio_dma_map(0x7f1cccdf0fc0, 0xfebf1000, 0x1000, 0x7f1ccf493000) = -14 (Wrong address)<br></div><div><br></div><div>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).</div><div>Dmesg says nothing both on the host and the guest.</div><div>This happens both using libvirt and without, but I've also tried:</div><div> - 5.4 instead of 5.3 kernel;</div><div> - Manjaro and Fedora host;</div><div> - booting in legacy instead of UEFI;</div><div></div><div> - binding to vfio-pci via kernel parameters instead of doing it after boot;</div><div> - using different QEMU machines;</div><div> - using OVMF or SeaBIOS;</div><div> - using KVM or not.</div><div><br></div><div>None of this made any difference.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Anyway, my laptop is running a 9th gen CoffeeLake Refresh H-series CPU on Manjaro with Linux 5.3 as the main system.</div><div><br></div><div>Thank you very much,</div><div><br></div><div>Davide.</div></div>