From: Scott Wood <scottwood@freescale.com>
To: Alexander Graf <agraf@suse.de>
Cc: <kvm-ppc@vger.kernel.org>,
"kvm@vger.kernel.org mailing list" <kvm@vger.kernel.org>,
Marcelo Tosatti <mtosatti@redhat.com>,
Gleb Natapov <gleb@redhat.com>
Subject: Re: [PATCH 15/17] KVM: PPC: Support irq routing and irqfd for in-kernel MPIC
Date: Fri, 19 Apr 2013 13:02:41 -0500 [thread overview]
Message-ID: <1366394561.8828.2@snotra> (raw)
In-Reply-To: <1366380388-25926-16-git-send-email-agraf@suse.de> (from agraf@suse.de on Fri Apr 19 09:06:26 2013)
On 04/19/2013 09:06:26 AM, Alexander Graf wrote:
> diff --git a/Documentation/virtual/kvm/devices/mpic.txt
> b/Documentation/virtual/kvm/devices/mpic.txt
> index ce98e32..dadc1e0 100644
> --- a/Documentation/virtual/kvm/devices/mpic.txt
> +++ b/Documentation/virtual/kvm/devices/mpic.txt
> @@ -35,3 +35,14 @@ Groups:
>
> "attr" is the IRQ number. IRQ numbers for standard sources are
> the
> byte offset of the relevant IVPR from EIVPR0, divided by 32.
> +
> +IRQ Routing:
> +
> + The MPIC emulation supports IRQ routing. Only a single MPIC device
> can
> + be instantiated. Once that device has been created, it's available
> as
> + irqchip id 0.
> +
> + This irqchip 0 has 256 interrupt pins. These pins reflect the SRC
> pins
> + on the MPIC controller.
This irqchip 0 has 256 interrupt pins, which expose the interrupts in
the main array of interrupt sources (a.k.a. "SRC" interrupts). The
numbering is the same as the MPIC device tree binding -- based on the
register offset from the beginning of the sources array, without regard
to any subdivisions in chip documentation such as "internal" or
"external" interrupts. Default routes are established for these pins,
with the GSI being equal to the pin number.
> + Access to on-SRC registers is not implemented through IRQ routing
> mechanisms.
s/on-SRC registers/non-SRC interrupts/
> diff --git a/arch/powerpc/kvm/mpic.c b/arch/powerpc/kvm/mpic.c
> index 10bc08a..d137df8 100644
> --- a/arch/powerpc/kvm/mpic.c
> +++ b/arch/powerpc/kvm/mpic.c
> @@ -1029,6 +1029,7 @@ static int openpic_cpu_write_internal(void
> *opaque, gpa_t addr,
> struct irq_source *src;
> struct irq_dest *dst;
> int s_IRQ, n_IRQ;
> + int notify_eoi = -1;
>
> pr_debug("%s: cpu %d addr %#llx <= 0x%08x\n", __func__, idx,
> addr, val);
> @@ -1087,6 +1088,8 @@ static int openpic_cpu_write_internal(void
> *opaque, gpa_t addr,
> }
>
> IRQ_resetbit(&dst->servicing, s_IRQ);
> + /* Notify listeners that the IRQ is over */
> + notify_eoi = s_IRQ;
> /* Set up next servicing IRQ */
> s_IRQ = IRQ_get_next(opp, &dst->servicing);
> /* Check queued interrupts. */
> @@ -1104,6 +1107,12 @@ static int openpic_cpu_write_internal(void
> *opaque, gpa_t addr,
> break;
> }
>
> + if (notify_eoi != -1) {
> + spin_unlock_irq(&opp->lock);
> + kvm_notify_acked_irq(opp->kvm, 0, notify_eoi);
> + spin_lock_irq(&opp->lock);
> + }
I'd rather not have the "_irq" here, which could break if we enter this
patch via an "_irqsave" (I realize there currently is no such path that
reaches EOI emulation).
Will we ever set notify_eoi when addr != EOI? I'm wondering why it was
moved out of the switch statement, instead of being put at the end of
the case EOI: code.
> +/*
> + * Return value:
> + * < 0 Interrupt was ignored (masked or not delivered for other
> reasons)
> + * = 0 Interrupt was coalesced (previous irq is still pending)
> + * > 0 Number of CPUs interrupt was delivered to
> + */
> +static int mpic_set_irq(struct kvm_kernel_irq_routing_entry *e,
> + struct kvm *kvm, int irq_source_id, int level,
> + bool line_status)
> +{
> + u32 irq = e->irqchip.pin;
> + struct openpic *opp = kvm->arch.mpic;
> +
> + spin_lock_irq(&opp->lock);
> + openpic_set_irq(opp, irq, level);
> + spin_unlock_irq(&opp->lock);
Use irqsave here and in kvm_set_msi. The latter can already be called
with interrupts disabled, and we may want to do the same for non-MSIs
once we start assigning non-PCI devices (where there's no longer the
excuse of "if you want it to be fast, use MSIs").
-Scott
next prev parent reply other threads:[~2013-04-19 18:02 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-19 14:06 [PATCH 00/17] KVM: PPC: In-kernel MPIC support with irqfd v3 Alexander Graf
2013-04-19 14:06 ` [PATCH 01/17] KVM: Add KVM_IRQCHIP_NUM_PINS in addition to KVM_IOAPIC_NUM_PINS Alexander Graf
2013-04-25 10:18 ` Michael S. Tsirkin
2013-04-19 14:06 ` [PATCH 02/17] KVM: Introduce CONFIG_HAVE_KVM_IRQ_ROUTING Alexander Graf
2013-04-25 10:18 ` Michael S. Tsirkin
2013-04-19 14:06 ` [PATCH 03/17] KVM: Drop __KVM_HAVE_IOAPIC condition on irq routing Alexander Graf
2013-04-25 10:19 ` Michael S. Tsirkin
2013-04-19 14:06 ` [PATCH 04/17] KVM: Remove kvm_get_intr_delivery_bitmask Alexander Graf
2013-04-25 10:19 ` Michael S. Tsirkin
2013-04-19 14:06 ` [PATCH 05/17] KVM: Move irq routing to generic code Alexander Graf
2013-04-25 10:19 ` Michael S. Tsirkin
2013-04-19 14:06 ` [PATCH 06/17] KVM: Extract generic irqchip logic into irqchip.c Alexander Graf
2013-04-25 10:19 ` Michael S. Tsirkin
2013-04-19 14:06 ` [PATCH 07/17] KVM: Move irq routing setup to irqchip.c Alexander Graf
2013-04-25 10:20 ` Michael S. Tsirkin
2013-04-19 14:06 ` [PATCH 08/17] KVM: Move irqfd resample cap handling to generic code Alexander Graf
2013-04-25 10:21 ` Michael S. Tsirkin
2013-04-19 14:06 ` [PATCH 09/17] kvm: add device control API Alexander Graf
2013-04-19 14:06 ` [PATCH 10/17] kvm/ppc/mpic: import hw/openpic.c from QEMU Alexander Graf
2013-04-19 14:06 ` [PATCH 11/17] kvm/ppc/mpic: remove some obviously unneeded code Alexander Graf
2013-04-19 14:06 ` [PATCH 12/17] kvm/ppc/mpic: adapt to kernel style and environment Alexander Graf
2013-04-19 14:06 ` [PATCH 13/17] kvm/ppc/mpic: in-kernel MPIC emulation Alexander Graf
2013-04-19 14:06 ` [PATCH 14/17] kvm/ppc/mpic: add KVM_CAP_IRQ_MPIC Alexander Graf
2013-04-19 14:06 ` [PATCH 15/17] KVM: PPC: Support irq routing and irqfd for in-kernel MPIC Alexander Graf
2013-04-19 18:02 ` Scott Wood [this message]
2013-04-25 9:58 ` Alexander Graf
2013-04-25 16:53 ` Scott Wood
2013-04-23 6:38 ` Paul Mackerras
2013-04-25 10:02 ` Alexander Graf
2013-04-19 14:06 ` [PATCH 16/17] KVM: PPC: MPIC: Add support for KVM_IRQ_LINE Alexander Graf
2013-04-19 18:51 ` Scott Wood
2013-04-25 11:30 ` Alexander Graf
2013-04-25 14:49 ` Alexander Graf
2013-04-25 19:03 ` Scott Wood
2013-04-25 21:13 ` Alexander Graf
2013-05-01 13:15 ` Marcelo Tosatti
2013-04-19 14:06 ` [PATCH 17/17] KVM: PPC: MPIC: Restrict to e500 platforms Alexander Graf
2013-04-25 10:24 ` [PATCH 00/17] KVM: PPC: In-kernel MPIC support with irqfd v3 Michael S. Tsirkin
-- strict thread matches above, loose matches on Subject: below --
2013-04-18 14:11 [PATCH 00/17] KVM: PPC: In-kernel MPIC support with irqfd Alexander Graf
2013-04-18 14:11 ` [PATCH 15/17] KVM: PPC: Support irq routing and irqfd for in-kernel MPIC Alexander Graf
2013-04-18 21:39 ` Scott Wood
2013-04-19 0:15 ` Alexander Graf
2013-04-19 0:50 ` Scott Wood
2013-04-19 1:09 ` Alexander Graf
2013-04-19 1:37 ` Scott Wood
2013-04-22 23:31 ` Scott Wood
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=1366394561.8828.2@snotra \
--to=scottwood@freescale.com \
--cc=agraf@suse.de \
--cc=gleb@redhat.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.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