[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] hw/intc/ioapic: Update KVM routes before redelivering IRQ, o
From: |
David Woodhouse |
Subject: |
Re: [PATCH] hw/intc/ioapic: Update KVM routes before redelivering IRQ, on RTE update |
Date: |
Sat, 11 Mar 2023 10:40:58 +0000 |
User-agent: |
Evolution 3.44.4-0ubuntu1 |
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.
smime.p7s
Description: S/MIME cryptographic signature
- Re: [PATCH] hw/intc/ioapic: Update KVM routes before redelivering IRQ, on RTE update, (continued)
- Re: [PATCH] hw/intc/ioapic: Update KVM routes before redelivering IRQ, on RTE update, David Woodhouse, 2023/03/06
- Re: [PATCH] hw/intc/ioapic: Update KVM routes before redelivering IRQ, on RTE update, David Woodhouse, 2023/03/06
- Re: [PATCH] hw/intc/ioapic: Update KVM routes before redelivering IRQ, on RTE update, Peter Xu, 2023/03/06
- Re: [PATCH] hw/intc/ioapic: Update KVM routes before redelivering IRQ, on RTE update, David Woodhouse, 2023/03/06
- Re: [PATCH] hw/intc/ioapic: Update KVM routes before redelivering IRQ, on RTE update, Peter Xu, 2023/03/08
- Re: [PATCH] hw/intc/ioapic: Update KVM routes before redelivering IRQ, on RTE update, David Woodhouse, 2023/03/09
- Re: [PATCH] hw/intc/ioapic: Update KVM routes before redelivering IRQ, on RTE update, Peter Xu, 2023/03/09
- Re: [PATCH] hw/intc/ioapic: Update KVM routes before redelivering IRQ, on RTE update, David Woodhouse, 2023/03/09
- Re: [PATCH] hw/intc/ioapic: Update KVM routes before redelivering IRQ, on RTE update, David Woodhouse, 2023/03/10
- Re: [PATCH] hw/intc/ioapic: Update KVM routes before redelivering IRQ, on RTE update, Peter Xu, 2023/03/10
- Re: [PATCH] hw/intc/ioapic: Update KVM routes before redelivering IRQ, on RTE update,
David Woodhouse <=