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: Mon, 22 Apr 2013 18:31:35 -0500 [thread overview]
Message-ID: <1366673495.10399.10@snotra> (raw)
In-Reply-To: <67A4FF0D-3BCF-42DB-9143-C87F1EF9CD0D@suse.de> (from agraf@suse.de on Thu Apr 18 19:15:46 2013)
On 04/18/2013 07:15:46 PM, Alexander Graf wrote:
>
> On 18.04.2013, at 23:39, Scott Wood wrote:
>
> > Do we really want any default routes? There's no platform notion
> of GSI
> > here, so how is userspace to know how the kernel set it up (or what
> GSIs
> > are free to be used for new routes) -- other than the "read the
> code"
> > answer I got when I asked about x86? :-P
>
> The "default routes" really are just "expose all pins 1:1 as GSI". I
> think it makes sense to have a simple default for user space that
> doesn't want to mess with irq routing.
>
> What GSIs are free for new routes doesn't matter. Routes are always
> completely rewritten as a while from user space. So when user space
> goes in and wants to change only a single line it has to lay out the
> full map itself anyway.
It looks like you already write the routes in your QEMU patches, so I'd
like to avoid adding MPIC default routes in KVM to keep things simple.
It's legacy baggage from day one. With default routes, what happens if
we later support instantiating multiple interrupt controllers?
-Scott
next prev parent reply other threads:[~2013-04-22 23:31 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-18 14:11 [PATCH 00/17] KVM: PPC: In-kernel MPIC support with irqfd Alexander Graf
2013-04-18 14:11 ` [PATCH 01/17] KVM: Add KVM_IRQCHIP_NUM_PINS in addition to KVM_IOAPIC_NUM_PINS Alexander Graf
2013-04-18 14:11 ` [PATCH 02/17] KVM: Introduce CONFIG_HAVE_KVM_IRQ_ROUTING Alexander Graf
2013-04-18 14:11 ` [PATCH 03/17] KVM: Drop __KVM_HAVE_IOAPIC condition on irq routing Alexander Graf
2013-04-18 14:11 ` [PATCH 04/17] KVM: Remove kvm_get_intr_delivery_bitmask Alexander Graf
2013-04-18 14:11 ` [PATCH 05/17] KVM: Move irq routing to generic code Alexander Graf
2013-04-18 14:11 ` [PATCH 06/17] KVM: Extract generic irqchip logic into irqchip.c Alexander Graf
2013-04-18 14:11 ` [PATCH 07/17] KVM: Move irq routing setup to irqchip.c Alexander Graf
2013-04-18 14:11 ` [PATCH 08/17] KVM: Move irqfd resample cap handling to generic code Alexander Graf
2013-04-18 14:11 ` [PATCH 09/17] kvm: add device control API Alexander Graf
2013-04-18 14:11 ` [PATCH 10/17] kvm/ppc/mpic: import hw/openpic.c from QEMU Alexander Graf
2013-04-18 14:11 ` [PATCH 11/17] kvm/ppc/mpic: remove some obviously unneeded code Alexander Graf
2013-04-18 14:11 ` [PATCH 12/17] kvm/ppc/mpic: adapt to kernel style and environment Alexander Graf
2013-04-18 14:11 ` [PATCH 13/17] kvm/ppc/mpic: in-kernel MPIC emulation Alexander Graf
2013-04-18 14:11 ` [PATCH 14/17] kvm/ppc/mpic: add KVM_CAP_IRQ_MPIC 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 [this message]
2013-04-18 14:11 ` [PATCH 16/17] KVM: PPC: MPIC: Add support for KVM_IRQ_LINE Alexander Graf
2013-04-18 14:11 ` [PATCH 17/17] KVM: PPC: MPIC: Restrict to e500 platforms Alexander Graf
2013-04-18 14:29 ` Scott Wood
2013-04-18 14:52 ` Alexander Graf
-- strict thread matches above, loose matches on Subject: below --
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 15/17] KVM: PPC: Support irq routing and irqfd for in-kernel MPIC Alexander Graf
2013-04-19 18:02 ` Scott Wood
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
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=1366673495.10399.10@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