qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Eric Auger <eric.auger@linaro.org>,
	eric.auger@st.com, christoffer.dall@linaro.org,
	qemu-devel@nongnu.org, kim.phillips@freescale.com,
	a.rigo@virtualopensystems.com
Cc: peter.maydell@linaro.org, patches@linaro.org,
	stuart.yoder@freescale.com, alex.williamson@redhat.com,
	christophe.barnichon@st.com, a.motakis@virtualopensystems.com,
	kvmarm@lists.cs.columbia.edu
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	[thread overview]
Message-ID: <53AB3EF8.7040401@suse.de> (raw)
In-Reply-To: <1401695374-4287-6-git-send-email-eric.auger@linaro.org>


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 <eric.auger@linaro.org>

  reply	other threads:[~2014-06-25 21:28 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-02  7:49 [Qemu-devel] [RFC v3 00/10] KVM platform device passthrough Eric Auger
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 01/10] hw/arm/virt: add a xgmac device Eric Auger
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 02/10] vfio: move hw/misc/vfio.c to hw/vfio/pci.c Eric Auger
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 03/10] vfio: add vfio-platform support Eric Auger
2014-06-25 21:21   ` Alexander Graf
2014-06-26  7:47     ` Eric Auger
2014-06-26  9:56       ` Alexander Graf
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 04/10] vfio: simplifed DPRINTF calls using device name Eric Auger
2014-06-25 21:22   ` Alexander Graf
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 05/10] vfio: Add initial IRQ support in platform device Eric Auger
2014-06-25 21:28   ` Alexander Graf [this message]
2014-06-25 21:40     ` Alex Williamson
2014-06-26  8:41       ` Eric Auger
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 06/10] virt: Assign a VFIO platform device with -device option Eric Auger
2014-06-25 21:30   ` Alexander Graf
2014-06-26  8:53     ` Eric Auger
2014-06-26  9:25       ` Alexander Graf
2014-06-26  9:30         ` Eric Auger
2014-06-25 22:28   ` Peter Maydell
2014-06-25 22:28     ` Alexander Graf
2014-06-26  7:39       ` Eric Auger
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 07/10] Add EXEC_FLAG to VFIO DMA mappings Eric Auger
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 08/10] Add AMBA devices support to VFIO Eric Auger
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 09/10] Always use eventfd as notifying mechanism Eric Auger
2014-06-02  7:49 ` [Qemu-devel] [RFC v3 10/10] vfio: Add irqfd support in platform device Eric Auger
2014-06-25 21:35   ` Alexander Graf
2014-06-25 21:54     ` Alex Williamson
2014-06-25 22:02       ` Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53AB3EF8.7040401@suse.de \
    --to=agraf@suse.de \
    --cc=a.motakis@virtualopensystems.com \
    --cc=a.rigo@virtualopensystems.com \
    --cc=alex.williamson@redhat.com \
    --cc=christoffer.dall@linaro.org \
    --cc=christophe.barnichon@st.com \
    --cc=eric.auger@linaro.org \
    --cc=eric.auger@st.com \
    --cc=kim.phillips@freescale.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=patches@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stuart.yoder@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).