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
