qemu-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]