[RFC PATCH 0/5] Xen PIRQ support

[David Woodhouse <dwmw2@infradead.org>]

This continues to build on the basic Xen on KVM platform support from 
https://lore.kernel.org/qemu-devel/20230110122042.1562155-1-dwmw2@infradead.org/

We're working on hooking up the PV backend devices, and the biggest 
remaining noticeably missing part was PIRQ support. This allows a Xen 
guest to route GSI and MSI interrupts to event channels instead of being 
delivered via the emulated I/OAPIC or local APIC respectively.

It starts relatively simple, with the basic hypercalls and infrastructure
for tracking/migrating the PIRQ table (and as I type this I've just
remembered I forgot to write the post_load function to reconstitute the
data structures which explicitly *state* that they need to be rebuilt).

I'm particularly interested in opinions on the hook in gsi_handler() 
which lets the Xen emulation 'eat' the event instead of passing it to 
the I/OAPIC.

I did ponder replacing the qemu_irq in gsi_state->ioapic_irq[n] when
GSI#n is redirected to a PIRQ, but I figured that was worse.

I definitely need to rethink the locking a little bit to avoid the 
potential for deadlock when gsi_handler calls back into the evtchn code 
to translate the event channel GSI. It's non-trivial to drop the lock 
before sending the IRQ; maybe just a different lock with a smaller 
scope. A previous implementation of event channels was a bit more 
lockless, with atomic updates of the port table (the port_info fits in a 
uint64_t). But now we have all the interesting fast paths accelerated in 
the kernel that didn't seem worth it, so I went with simple locking... 
too simple, it seems.

There's a similar recursive locking issue when pirq_bind_port() wants to 
call kvm_update_msi_routes_all(), but is already holding the lock that 
we'd take again when called to redo a translation. (And I still don't 
much like the way that kvm_update_msi_routes_all() has to have a list of 
PCI devices and actually recalculates the routes at all, instead of just 
detaching the IRQFD and letting them be recalculated on demand. But I 
was trying to avoid actually fixing that this week).

David Woodhouse (5):
      i386/xen: Implement HYPERVISOR_physdev_op
      hw/xen: Implement emulated PIRQ hypercall support
      hw/xen: Support GSI mapping to PIRQ
      hw/xen: [FIXME] Avoid deadlock in xen_evtchn_set_gsi()
      hw/xen: Support MSI mapping to PIRQ

 hw/i386/kvm/trace-events     |   4 ++
 hw/i386/kvm/trace.h          |   1 +
 hw/i386/kvm/xen-stubs.c      |  11 ++++
 hw/i386/kvm/xen_evtchn.c     | 461 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 hw/i386/kvm/xen_evtchn.h     |  22 +++++++
 hw/i386/x86.c                |  15 +++++
 hw/pci/msi.c                 |  13 ++++
 hw/pci/msix.c                |   7 ++-
 hw/pci/pci.c                 |  14 +++++
 meson.build                  |   1 +
 target/i386/kvm/kvm.c        |  12 +++-
 target/i386/kvm/kvm_i386.h   |   2 +
 target/i386/kvm/xen-compat.h |  19 ++++++
 target/i386/kvm/xen-emu.c    | 136 +++++++++++++++++++++++++++++++++++++++++-
 14 files changed, 712 insertions(+), 6 deletions(-)