From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Alexander Graf <agraf@suse.de>,
kvm@vger.kernel.org, Peter Maydell <peter.maydell@linaro.org>,
Jan Kiszka <jan.kiszka@siemens.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
David Gibson <dwg@au1.ibm.com>
Subject: Re: [Qemu-devel] Interrupt controller updates
Date: Fri, 23 Nov 2012 08:00:20 +1100 [thread overview]
Message-ID: <1353618020.17856.43.camel@pasglop> (raw)
In-Reply-To: <50ADFDA8.9010003@redhat.com>
On Thu, 2012-11-22 at 11:25 +0100, Paolo Bonzini wrote:
> > Again, from memory, you were volunteered to do the initial x86
> change so
> > we could piggy back on it :-) Or do I remember wrong ?
>
> Please suggest an API, then we can work out the x86 changes. I can
> volunteer myself, but I wasn't in the BOF so I need something more
> concrete.
Oh it's simple enough initially, just move the ioctl call from generic
kvm init to machine init. The problem is then to add an argument, since
that essentially means changing the ioctl number, but we need that for
all archs where the interrupt subsystem can be fundamentally different
based on the platform.
Basically, what was discussed in the BOF was that we split the init:
* The existing ioctl moves to early machine init (before VCPUs) and
gets that argument to define the type of interrupt subsystem to use. It
causes powerpc to instanciate ICPs per VCPUs for example. On archs that
don't have a per-vcpu structure (equivalent of local APIC or ICP), all
it does is enable subsequent irq related ioctls to work (it's just an
"enable" flag).
* A new ioctl is used to actually instanciate external interrupt
controllers (GIC on ARM, ICS for ppc/pseries, MPIC for ppc/mpic, ...).
This is used later by the PIC code itself when the former ioctl has
enabled "in kernel PIC"
* A new ioctl is used for platforms that need to be able to adjust the
base address of a PIC (arm/GIC, ppc/mpic)
We have other things to look at (mostly along the MSI routing calls in
qemu that need to be changed to be PCI bridge hooks populated by the
platform) but that's the starting point.
Cheers,
Ben.
next prev parent reply other threads:[~2012-11-22 21:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-21 1:07 [Qemu-devel] Interrupt controller updates Benjamin Herrenschmidt
2012-11-21 8:30 ` Jan Kiszka
2012-11-22 10:25 ` Paolo Bonzini
2012-11-22 21:00 ` Benjamin Herrenschmidt [this message]
2012-11-22 21:14 ` Peter Maydell
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=1353618020.17856.43.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=agraf@suse.de \
--cc=dwg@au1.ibm.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/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).