Re: [RFC PATCH] KVM: Add module for IRQ forwarding

[Alex Williamson <alex.williamson@redhat.com>]

On Wed, 13 May 2020 09:02:16 +0200
Paolo Bonzini <pbonzini@redhat.com> 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