[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v3 05/10] vfio: Add initial IRQ support in platfor
From: |
Alex Williamson |
Subject: |
Re: [Qemu-devel] [RFC v3 05/10] vfio: Add initial IRQ support in platform device |
Date: |
Wed, 25 Jun 2014 15:40:52 -0600 |
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
- [Qemu-devel] [RFC v3 00/10] KVM platform device passthrough, Eric Auger, 2014/06/02
- [Qemu-devel] [RFC v3 08/10] Add AMBA devices support to VFIO, Eric Auger, 2014/06/02
- [Qemu-devel] [RFC v3 07/10] Add EXEC_FLAG to VFIO DMA mappings, Eric Auger, 2014/06/02
- [Qemu-devel] [RFC v3 09/10] Always use eventfd as notifying mechanism, Eric Auger, 2014/06/02
- [Qemu-devel] [RFC v3 10/10] vfio: Add irqfd support in platform device, Eric Auger, 2014/06/02
[Qemu-devel] [RFC v3 06/10] virt: Assign a VFIO platform device with -device option, Eric Auger, 2014/06/02