On Wed, 11 Jan 2023 19:08:44 +0000 David Woodhouse <[email protected]> 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. 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, Alex
