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

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

On Thu, 14 May 2020 23:17:29 +0200
Paolo Bonzini <pbonzini@redhat.com> wrote:

> On 14/05/20 19:44, Micah Morton wrote:
> > I realize this may seem like an over-use of VFIO, but I'm actually
> > coming from the angle of wanting to assign _most_ of the important
> > hardware on my device to a VM guest, and I'm looking to avoid
> > emulation wherever possible. Of course there will be devices like the
> > IOAPIC for which emulation is unavoidable, but I think emulation is
> > avoidable here for the busses we've mentioned if there is a way to
> > forward arbitrary interrupts into the guest.
> > 
> > Since all these use cases are so close to working with vfio-pci right
> > out of the box, I was really hoping to come up with a simple and
> > generic solution to the arbitrary interrupt problem that can be used
> > for multiple bus types.  
> 
> I shall defer to Alex on this, but I think the main issue here is that
> these interrupts are not visible to Linux as pertaining to the pci-stub
> device.  Is this correct?

Yes.  Allowing a user to grant themselves access to an arbitrary
interrupt is a non-starter, vfio-pci needs to somehow know that the
user is entitled to that interrupt.  If we could do that, then we could
just add it as a device specific interrupt.  But how do we do that?

The quirk method to this might be to key off of the PCI vendor and
device ID of the PCI i2c controller, lookup DMI information to know if
we're on the platform that has this fixed association, and setup the
extra interrupt.  The more extensible, but potentially bloated solution
might be for vfio-pci to recognize the class code for a i2c controller
and implement a very simple bus walk at device probe time that collects
external dependencies.  I don't really know how the jump is made from
that bus walk to digging the interrupt resource out of ACPI though or
how many LoC would be required to perform the minimum possible
discovery to collect this association.

I notice in this RFC patch that you're using an exclusive interrupt for
level triggered interrupts and therefore masking at the APIC.
Requiring an exclusive interrupt is often a usability issue for PCI
devices that don't support DisINTx and obviously we don't have that for
non-PCI sub-devices.  What type of interrupt do you actually need for
this device?  Thanks,

Alex