On Wed, 13 May 2020 09:02:16 +0200 Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > On 12/05/20 19:14, Alex Williamson wrote: > > But why not assign the individual platform devices via vfio-platform > > rather than assign the i2c controller via vfio-pci and then assembling > > the interrupts from those sub-devices with this ad-hoc interface? An > > emulated i2c controller in the guest could provide the same discovery > > mechanism as is available in the host. > > I agree. I read the whole discussion, but I still don't understand why > this is not using vfio-platform. > > 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 i2c controller is a PCI device, it can be assigned with vfio-pci and we can use it to probe the i2c bus and find the sub-devices. However 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. So the guest needs an ACPI blob to describe the interrupt and then access to the interrupt. This is what's new here. 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. Thanks, Alex
