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: Alexander Graf
Subject: Re: [Qemu-devel] [RFC v3 05/10] vfio: Add initial IRQ support in platform device
Date: Wed, 25 Jun 2014 23:28:24 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0


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.


Alex


A single IRQ can be forwarded to the guest at a time, ie. before a
new virtual IRQ to be injected, the previous active one must have
completed.

When no IRQ is pending anymore, fast path can be restored. This is
done on mmap_timer scheduling.

irqfd support will be added in a subsequent patch. irqfd brings a
framework where the eventfd is handled on kernel side instead of in
user-side as currently done, hence improving the performance.

Although the code is prepared to support multiple IRQs, this is not
tested at that stage.

Tested on Calxeda Midway xgmac which can be directly assigned to one
guest (unfortunately only the main IRQ is exercised). A KVM patch is
required to invalidate stage2 entries on RAM memory region destruction
(https://patches.linaro.org/27691/). Without that patch, slow/fast path
switch cannot work.

change v2 -> v3:

- Move mmap_timer and mmap_timeout in new VFIODevice struct as
   PCI/platform factorization.
- multiple IRQ handling (a pending IRQ queue is added) - not tested -
- create vfio_mmap_set_enabled as in PCI code
- name of irq changed in virt

Signed-off-by: Eric Auger <address@hidden>




reply via email to

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