From: Gleb Natapov <gleb@redhat.com>
To: Scott Wood <scottwood@freescale.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
Paul Mackerras <paulus@samba.org>, Alexander Graf <agraf@suse.de>,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
Subject: Re: [PATCH 3/9] KVM: PPC: Book3S: Add kernel emulation for the XICS interrupt controller
Date: Sun, 24 Feb 2013 14:08:37 +0000 [thread overview]
Message-ID: <20130224140837.GB4284@redhat.com> (raw)
In-Reply-To: <1361406051.31212.13@snotra>
On Wed, Feb 20, 2013 at 06:20:51PM -0600, Scott Wood wrote:
> On 02/20/2013 01:58:54 PM, Marcelo Tosatti wrote:
> >This is probably a stupid question, but why the
> >KVM_SET_IRQCHIP/KVM_SET_GSI_ROUTING interface is not appropriate for
> >your purposes?
> >
> >x86 sets up a default GSI->IRQCHIP PIN mapping on creation (during
> >KVM_SET_IRQCHIP), but it can be modified with KVM_SET_GSI_ROUTING.
>
> To start, the whole IRQ routing stuff is poorly documented.
>
> Am I supposed to make up GSI numbers and use the routing thing to
> associate them with real interrupts?
You can consider GSI to be a cookie that you use to refer to whatever
data you've put into routing table by KVM_IRQ_LINE/irqfd interface.
Even on x86, when irq routing is used to inject MSI interrupt, this is
exactly how GSI is used. In MSI case it does not have a meaning besides
"look at that interrupt entry to see what MSI should be injected".
> Are there constraints on what
> sort of GSI numbers I can choose (I now see in the code that
> KVM_MAX_IRQ_ROUTES is returned from the capability check, but where
> is that documented?
The only constrain is that the number should be smalled than
KVM_MAX_IRQ_ROUTES, but this is implementation detail. Current
implementation uses array to map from GSI to a data, if a lot more
entries then currently allowed is needed implementation may be changed
to different data structure.
> It looks like the APIC implementation has
> default routes, where is that documented?)?
It is very PC centric, should not be even compiled for other arches.
> Where does the code
> live to manage this table, and how APICy is it (looks like the
> answer is "irq_comm.c, and very")?
It is a mistake to refer to the irq routing table as APICy :). It is
certainly PC centric currently, but there is at least one HW layer
between it and the APIC. PC has global GSI space, each GSI can be
delivered via different irq chip. Some GSIs can be delivered through
multiple irq chips. Irq routing table provides mapping between GSI and
irq chips it should be delivered through. Some irq chips deliver
interrupt via APIC some not, but this is different story.
The work is needed to make the code not PC centric, but it should not be
a lot of work.
> I suppose I could write another
> implementation of the table management code for MPIC, though the
> placement of "irqchip" inside the route entry, rather than as an
> argument to KVM_IRQ_LINE, suggests the table is supposed to be
> global, not in the individual interrupt controller.
>
Yes, it is global. It sits between emulated devices and irq chips.
--
Gleb.
next prev parent reply other threads:[~2013-02-24 14:08 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-14 23:59 [PATCH 0/9] In-kernel XICS interrupt controller emulation Paul Mackerras
2013-02-14 23:59 ` [PATCH 1/9] KVM: PPC: Book3S: Add infrastructure to implement kernel-side RTAS calls Paul Mackerras
2013-03-21 8:52 ` Alexander Graf
2013-04-04 5:37 ` Paul Mackerras
2013-04-04 9:49 ` Alexander Graf
2013-04-04 22:38 ` Paul Mackerras
2013-04-19 15:16 ` Alexander Graf
2013-02-15 0:00 ` [PATCH 2/9] KVM: PPC: Remove unused argument to kvmppc_core_dequeue_external Paul Mackerras
2013-03-21 8:58 ` Alexander Graf
2013-02-15 0:01 ` [PATCH 3/9] KVM: PPC: Book3S: Add kernel emulation for the XICS interrupt controller Paul Mackerras
2013-02-15 20:05 ` Scott Wood
2013-02-15 23:18 ` Paul Mackerras
2013-02-15 23:59 ` Scott Wood
2013-02-16 2:56 ` Paul Mackerras
2013-02-16 3:57 ` Scott Wood
2013-02-16 4:51 ` Paul Mackerras
2013-02-18 22:43 ` Scott Wood
2013-02-20 0:41 ` Paul Mackerras
2013-02-20 1:01 ` Scott Wood
2013-02-20 19:58 ` Marcelo Tosatti
2013-02-21 0:20 ` Scott Wood
2013-02-21 1:09 ` Marcelo Tosatti
2013-02-21 1:45 ` Scott Wood
2013-02-24 14:08 ` Gleb Natapov [this message]
2013-02-25 0:59 ` Paul Mackerras
2013-03-21 9:20 ` Alexander Graf
2013-02-15 0:01 ` [PATCH 4/9] KVM: PPC: Book3S: Generalize interfaces to interrupt controller emulation Paul Mackerras
2013-02-15 0:02 ` [PATCH 5/9] KVM: PPC: Book3S: Facilities to save/restore XICS presentation ctrler state Paul Mackerras
2013-02-15 0:02 ` [PATCH 6/9] KVM: PPC: Book3S HV: Speed up wakeups of CPUs on HV KVM Paul Mackerras
2013-02-15 0:03 ` [PATCH 7/9] KVM: PPC: Book3S HV: Add support for real mode ICP in XICS emulation Paul Mackerras
2013-02-15 0:03 ` [PATCH 8/9] KVM: PPC: Book3S HV: Improve real-mode handling of external interrupts Paul Mackerras
2013-02-15 0:04 ` [PATCH 9/9] KVM: PPC: Book3S: Add support for ibm,int-on/off RTAS calls Paul Mackerras
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=20130224140837.GB4284@redhat.com \
--to=gleb@redhat.com \
--cc=agraf@suse.de \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=paulus@samba.org \
--cc=scottwood@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