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

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 2344 bytes --]

On Fri, 2023-03-10 at 15:13 -0500, Peter Xu wrote:
> 
> > 
> > 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.

For the translation we don't need a reverse path.

When a range of 'cookies' is invalidated, the generic irqroute code
just kicks the irqfd out of the routing table.

That means the device code gets notified by its *own* eventfd. It tries
to say "deliver <this> virq", gets a "nope, it's invalid", and then
reprovides the original MSI information to be (re)translated (and to
raise a fault if it's invalid now).

Looks a bit like this...

	if (timer.gsi == static_cast<uint32_t>(-1))
		return -1;

	if (irqchip_try_deliver_gsi(timer.gsi) >= 0)
		return 0;

	struct kvm_msi msi = read_timer_msi_reg(timer);
	if (irqchip_update_msi(timer.gsi, &msi, deliver_now = true) < 0)
		errno = 0;


Now, for the interrupt *acknowledge* (kvm_resample_fd_notify) we
absolutely need a reverse path, and we need that anyway regardless of
KVM routing — VFIO and the Xen event channel GSI can both be massively
cleaned up if we have that wired up from the EOI/intack. But that's
*mostly* a separate issue, except that of course we want to wire that
resamplefd up in the routing table *too* and make things consistent in
userspace vs. KVM.

> 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.

Yeah, that's definitely the intent.

When I first started playing with this in order to implement interrupt
remapping in my other VMM, I carefully drew out state diagrams in
pencil, tracking which eventfd was connected to userspace/KVM in
different states across first-trigger/masking/unmasking/live-update,
with a large 'WTF!!!' on the one of the state transitions from masked
to unmasked, when the IRQ happened anyway.

For QEMU I haven't even been able to write it out, because the logic is
split across different devices and handled differently in each. I think
it can be really simple.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]