public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@samba.org>
To: Marcelo Tosatti <mtosatti@redhat.com>
Cc: Scott Wood <scottwood@freescale.com>,
	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: Mon, 25 Feb 2013 11:59:54 +1100	[thread overview]
Message-ID: <20130225005954.GA12404@drongo> (raw)
In-Reply-To: <20130220195854.GA2029@amt.cnet>

On Wed, Feb 20, 2013 at 04:58:54PM -0300, 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.

So, I see Scott already answered from the point of view of his MPIC
emulation stuff, but I'll answer too from the point of view of my XICS
emulation code.

My understanding, possibly imperfect, is that in a real system the
routing of GSIs to IOAPICs would either be hardwired or set up by the
BIOS, described in ACPI tables, and not modified by the operating
system.  Is that correct?  So my belief is that the GSI routing is
fundamentally distinct from and handled differently from the routing
of interrupts to CPUs, which is fully under the control of the OS.

In the XICS model we have a set of interrupt sources, each identified
by a 24-bit number.  Control operations on an interrupt source just
identify the source by its number.  Thus the interrupt source number
is like a GSI, but we don't need to map that to a different space
(e.g. IOAPIC identifier and input number) in order to operate on it,
we can just operate on it directly.

Paul.

  parent reply	other threads:[~2013-02-25  0:59 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
2013-02-25  0:59             ` Paul Mackerras [this message]
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=20130225005954.GA12404@drongo \
    --to=paulus@samba.org \
    --cc=agraf@suse.de \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --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