On Wed, 2014-06-25 at 23:28 +0200, Alexander Graf wrote: > On 02.06.14 09:49, Eric Auger wrote: > > This patch brings a first support for device IRQ assignment to a > > KVM guest. Code is inspired of PCI INTx code. > > > > General principle of IRQ handling: > > > > when a physical IRQ occurs, VFIO driver signals an eventfd that was > > registered by the QEMU VFIO platform device. The eventfd handler > > (vfio_intp_interrupt) injects the IRQ through QEMU/KVM and also > > disables MMIO region fast path (where MMIO regions are mapped as > > RAM). The purpose is to trap the IRQ status register guest reset. > > The physical interrupt is unmasked on the first read/write in any > > MMIO region. It was masked in the VFIO driver at the instant it > > signaled the eventfd. > > This doesn't sound like a very promising generic scheme to me. I can > easily see devices requiring 2 or 3 or more accesses until they're > pulling down the IRQ line. During that time interrupts will keep firing, > queue up in the irqfd and get at us as spurious interrupts. > > Can't we handle it like PCI where we require devices to not share an > interrupt line? Then we can just wait until the EOI in the interrupt > controller. QEMU's interrupt abstraction makes this really difficult and something that's not generally necessary outside of device assignment. I spent a long time trying to figure out how we'd do it for PCI before I came up with this super generic hack that works surprisingly well. Yes, we may get additional spurious interrupts, but from a host perspective they're rate limited by the guest poking hardware, so there's a feedback loop. Also note that assuming this is the same approach we take for PCI, this mode is only used for the non-KVM accelerated path. When we have a KVM irqchip that supports a resampling irqfd then we can get an eventfd signal back at the point when we should unmask the interrupt on the host. Creating a cross-architecture QEMU interface to give you a callback when the architecture's notion of a resampling event occurs is not a trivial undertaking. Thanks, Alex _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
