On Wed, 11 Jan 2023 19:50:15 +0000 David Woodhouse <dw...@infradead.org> wrote:
> On Wed, 2023-01-11 at 12:43 -0700, Alex Williamson wrote: > > On Wed, 11 Jan 2023 19:08:44 +0000 > > David Woodhouse <dw...@infradead.org> wrote: > > > > > On Wed, 2023-01-11 at 11:29 -0700, Alex Williamson wrote: > > > > > > > > Nice. IIRC, we ended up with the hack solution we have today in vfio > > > > because there was too much resistance to callbacks that were only > > > > necessary for vfio in the past. Once we had KVM resampling support, > > > > it simply wasn't worth the effort for a higher latency solution to > > > > fight that battle, so we implemented what could best be described as > > > > a universal workaround embedded in vfio. > > > > > > > > Clearly a callback is preferable, and yes, that's how we operate with > > > > KVM resampling and unmasking INTx, so in theory plumbing this to our > > > > existing eoi callback and removing the region toggling ought to do > > > > the right thing. Thanks, > > > > > > Well, I'm happy for the Xen support be a second use case which means > > > it's no longer "only necessary for VFIO", and keep prodding at it if > > > that's going to be useful... > > > > Welcome aboard. I take it from your cover letter than non-x86 > > architectures would be on your todo list. Ideally the ack callback > > would simply be a requirement for any implementation of a new interrupt > > controller, but that's where we get into striking a balance of device > > assignment imposing requirements on arbitrary architectures that may or > > may not care, or even support, device assignment. > > Right. We'd probably want to do it for those interrupt controllers > which could be behind PCI host controllers that might have VFIO devices > attached. > > > This is the... dare I say, elegance of the region access hack. It's > > obviously not pretty or performant, but it universally provides an > > approximation of the behavior of an emulated device, ie. some form of > > guest access to the device is required to de-assert the interrupt. > > > > We probably need some way to detect the interrupt controller support > > for the callback mechanism so we can generate an appropriate user > > warning to encourage development of that support and fall back to our > > current hack for some degree of functionality. Thanks, > > Yeah, I pondered that. It's not that hard to do; have the interrupt > controller indicate that a given qemu_irq supports EOI notifications, > and then when the VFIO or other event source calls > qemu_set_irq_ack_callback() it can get a failure which will cause it to > use the fallback mode. > > Happy to look at wiring this up through the pci_set_irq() mechanisms if > it's not going to be rejected out of hand. Careful about making too many assumptions around PCI, it's clearly the most used but vfio is bus agnostic and we do have vfio-platform support as well as some weird s390 devices. There's nothing PCI specific about a level triggered interrupt, so preferably all this sits a layer below the PCI interfaces. Thanks, Alex
