The pseries machine type has the odd property that it's root irq chip can be completely changed at runtime. This comes about because PAPR feature negotiation lets the guest choose between the old XICS style or new XIVE style PIC. It's possible, because both PICs are paravirtualized via hypercalls.
VFIO needs to wire up device interrupts directly to the kernel irqchip to accelerate delivery, and that's broken by the irq chip change. This series introduces a new notifier to get this correctly updated when PAPR switchs irq chip. Caveats: * I'm not sure I've sufficiently pinned down the semantics of when exactly the new notifier should be called yet * It would kind of be niced to automatically fire the notifier from somewhere in the irq chip update routines, rather than at the PAPR level. I haven't seen a good way to do that (at least not without double firing it on every transition). * Patch 5/5 to work around spurious warnings is working a bit *too* well. On a Boston machine which allows in-kernel XICS, but not in-kernel XIVE, I (correctly) no longer get the spurious warning at initial start up (in XICS mode). However we incorrectly *don't* get the "failed to setup resample irqfd" warning after we negotiate features and switch to XIVE mode. I haven't had a chance to investigate, but I suspect a kernel bug where it's responding to KVM_IRQFD based on stale information about the kernel irqchip. David Gibson (5): kvm: Introduce KVM irqchip change notifier vfio/pci: Split vfio_intx_update() vfio/pci: Respond to KVM irqchip change notifier spapr: Handle irq backend changes with VFIO PCI devices spapr: Work around spurious warnings from vfio INTx initialization accel/kvm/kvm-all.c | 18 +++++++++++++++ accel/stubs/kvm-stub.c | 12 ++++++++++ hw/ppc/spapr_irq.c | 17 +++++++++++++- hw/vfio/pci.c | 51 ++++++++++++++++++++++++++++-------------- hw/vfio/pci.h | 2 ++ include/sysemu/kvm.h | 5 +++++ 6 files changed, 87 insertions(+), 18 deletions(-) -- 2.21.0