Re: [PATCH] hw/intc/ioapic: Update KVM routes before redelivering IRQ, on RTE update

[Peter Xu <peterx@redhat.com>]

On Fri, Mar 10, 2023 at 05:52:57PM +0000, David Woodhouse wrote:
> On Thu, 2023-03-09 at 11:55 -0500, Peter Xu wrote:
> > 
> > There're four devices that can hook onto this, IIUC.  Besides IOAPIC and
> > VFIO, there's also ivshmem and vhost.  IIUC we'll need to change all the
> > four devices to implement this.
> 
> If you grep for kvm_irqchip_add_irqfd_notifier() there are more than that.

Looks right to me.  I assume they're all line based IRQs routed later to
IOAPIC, so they're the real devices consuming the IOAPIC entries.

> There's a bunch of largely duplicated code, with different code paths
> for kvm_irqfds_enabled() and other variants. In code that I don't think
> should even have to *know* about KVM, should it? 
> 
> I think I'd like to provide a generic set of helpers which just allow
> callers to register a virtual IRQ and then trigger it manually and/or
> attach an irqfd (and a resamplefd, qv) to it.
> 
> This new helper code can then cope with listening in userspace on that
> fd if/when it needs to, and can even work for the non-KVM case. The
> actual devices get a *lot* simpler.
> 
> It'll *broadly* look like the existing kvm_irqchip_* functions but be a
> lot simpler to use.

IIUC what's missing is the reverse chain of notifications from e.g. IRTE to
the device, either via MSIs or via some pins of IOAPIC.

I don't think I have very good knowledge on the whole IRQ path yet so I
can't really tell anything useful, but what you said looks like a good
thing to have.  If it can cleanup things besides achieving the goal of
fault irq reporting it could be more worthwhile.

Thanks,

-- 
Peter Xu