On Thu, 14 May 2020 23:17:29 +0200 Paolo Bonzini <pbonzini@xxxxxxxxxx> 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
