On Thu, May 14, 2020 at 3:43 PM Alex Williamson <alex.williamson@xxxxxxxxxx> wrote: > > 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. The quirk method is interesting. I wonder if we have a guarantee for a given platform and PCI vendor/device which IRQ number/type will be used. If so that might be an option. Would you need to do a bus walk? I guess it would be possible to simply look at ACPI whenever you see a bus controller being assigned with VFIO. ACPI should tell you about all the sub-devices on that bus and their IRQ details. This is how vfio-platform (with DT, not ACPI) knows which IRQs to forward into the guest right? Is there a fundamental reason this is more difficult on x86 or is the code just not there since PCI generally precludes the need for this? > > 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, I don't have any reason to think the interrupts for sub-devices on the bus would be shared with any other PCI devices or platform devices. Are you asking if there's any chance the platform IRQs are shared rather than exclusive or are you saying there's some issue with presenting the exclusive IRQ to the guest as exclusive through PCI legacy-style interrupts? > > Alex >
