On 13/05/20 16:34, Alex Williamson wrote: >> Alternatively, if you assign the i2c controller, I don't understand why >> the guest doesn't discover interrupts on its own. Of course you need to >> tell the guest about the devices in the ACPI tables, but why is this new >> concept necessary? > > the interrupt for this sub-device is unrelated to the PCI > controller device, it's an entirely arbitrary (from our perspective) > relationship described via ACPI. Ok, that's what I was missing. > We could potentially use device specific interrupts to expose this via > the controller device, but then vfio-pci needs to learn how to > essentially become an i2c controller to enumerate the sub-devices and > collect external dependencies. This is not an approach I've embraced > versus the alternative of the host i2c driver claiming the PCI > controller, enumerating the sub-devices, and binding the resulting > device, complete with built-in interrupt support via vfio-platform. I agree that's the way to go. Perhaps adding arbitrary non-PCI interrupts, i.e. neither INTX nor MSI(-X), to vfio-pci could be acceptable. However, the device claim must claim them, and that seems hard to do when you rebind the PCI device to pci-stub. Paolo
