On 13/05/20 21:10, Micah Morton wrote: > * If we only care about the bus controller existing (in an emulated > fashion) enough for the guest to discover the device in question, this > could work. I’m concerned that power management could be an issue here > however. For instance, I have a touchscreen device assigned to the > guest (irq forwarding done with this module) that in response to the > screen being touched prepares the i2c controller for a transaction by > calling into the PM system which end up writing to the PCI config > space** (here https://elixir.bootlin.com/linux/v5.6.12/source/drivers/i2c/busses/i2c-designware-master.c#L435). > It seems like this kind of scenario expands the scope of what would > need to be supported by the emulated i2c controller, which is less > ideal. The way I have it currently working, vfio-pci emulates the PCI > config space so the guest can do power management by accessing that > space. This wouldn't be a problem. When the emulated i2c controller starts a transaction on th edevice, it will be performed by the host i2c controller and this will lead to the same config space write. I have another question: would it be possible to expose this IRQ through /dev/i2c-* instead of messing with VFIO? In fact, adding support for /dev/i2c passthrough to QEMU has long been a pet idea of mine (my usecase was different though: the idea was to write programs for a microcontroller on an ARM single board computer and run them under QEMU in emulation mode). It's not trivial, because there could be some impedence mismatch between the guest (which might be programmed against a low-level controller or might even do bit banging) and the i2c-dev interface which is more high level. Also QEMU cannot do clock stretching right now. However, it's certainly doable. >> (Finally, in the past we were doing device assignment tasks within KVM >> and it was a bad idea. Anything you want to do within KVM with respect >> to device assignment, someone else will want to do it from bare metal. > > Are you saying people would want to use this in non-virtualized > scenarios like running drivers in userspace without any VMM/guest? And > they could do that if this was part of VFIO and not part of KVM? Yes, see above for an example. Paolo
