From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Paul Mackerras <paulus@samba.org>,
Christoffer Dall <c.dall@virtualopensystems.com>,
Alexander Graf <agraf@suse.de>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
kvm-ppc <kvm-ppc@vger.kernel.org>
Subject: Re: [kvmarm] [RFC PATCH 0/3] KVM: ARM: Get rid of hardcoded VGIC addresses
Date: Fri, 26 Oct 2012 11:09:54 +0000 [thread overview]
Message-ID: <1351249794.12271.27.camel@pasglop> (raw)
In-Reply-To: <508A6D5A.1030007@siemens.com>
On Fri, 2012-10-26 at 13:00 +0200, Jan Kiszka wrote:
> And at latest there you will need the IRQ routing infrastructure of KVM.
> It tells KVM which "virtual IRQ" (badly named "GSI") triggers which
> event at which input, e.g. a physical IRQ line at some IRQ controller or
> a specific message at some MSI receiver. You shouldn't try to invent a
> Power wheel here, rather tune the existing one to become more generic.
> We could even try to get rid of that unfortunate GSI name (when leaving
> aliases behind), though that is cosmetic.
Ok, there must be something wrong with me, I still don't understand what
you are talking about.
What "MSI receiver" ? What physical IRQ line are you talking about ? How
is the kernel involved ?
The only cases I can think of are the association between a virtual
interrupt (ie, an interrupt in the guest interrupt number space) and an
in-kernel source for that interrupt, ie, vhost and PCI pass-through
essentially.
Anything else is under qemu control. IE. MSIs or LSIs generated by
emulated devices are just normal interrupt that go through our ioctl to
trigger the in-kernel source with the same number.
I don't see any "routing" happening anywhere in that picture really. The
firmware calls done by the guest to change the target of interrupts
(which CPU/presentation controller to direct a given interrupt to) are
handled entirely in the kernel in platform specific code and update our
internal ICS state.
> >
> > I might just miss some subtleties here but so far I haven't been able to
> > figure out how to "shoehorn" our stuff in the very x86-centric existing
> > interfaces to the kernel APICs. In fact all that code is in a generic
> > location in kvm but is really x86/ia64 centric and the interfaces seem
> > to be as well.
>
> That's not true in general, though you surely find a lot of traces and
> still a few concrete x86 bits under virt/kvm.
Well, I haven't found anything in virt/kvm/irq_comm.c that was of any
use to us. Again, I might be sufferring from a major misunderstanding
here but as far as I can tell, the model is totally different. Besides,
that file has a hard coded list of what looks like completely x86
specific mappings between "GSI" and "interrupt numbers" (again I don't
understand completely the distinction and I don't think we have anything
like it on power).
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Paul Mackerras <paulus@samba.org>,
Christoffer Dall <c.dall@virtualopensystems.com>,
Alexander Graf <agraf@suse.de>,
"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
kvm-ppc <kvm-ppc@vger.kernel.org>
Subject: Re: [kvmarm] [RFC PATCH 0/3] KVM: ARM: Get rid of hardcoded VGIC addresses
Date: Fri, 26 Oct 2012 22:09:54 +1100 [thread overview]
Message-ID: <1351249794.12271.27.camel@pasglop> (raw)
In-Reply-To: <508A6D5A.1030007@siemens.com>
On Fri, 2012-10-26 at 13:00 +0200, Jan Kiszka wrote:
> And at latest there you will need the IRQ routing infrastructure of KVM.
> It tells KVM which "virtual IRQ" (badly named "GSI") triggers which
> event at which input, e.g. a physical IRQ line at some IRQ controller or
> a specific message at some MSI receiver. You shouldn't try to invent a
> Power wheel here, rather tune the existing one to become more generic.
> We could even try to get rid of that unfortunate GSI name (when leaving
> aliases behind), though that is cosmetic.
Ok, there must be something wrong with me, I still don't understand what
you are talking about.
What "MSI receiver" ? What physical IRQ line are you talking about ? How
is the kernel involved ?
The only cases I can think of are the association between a virtual
interrupt (ie, an interrupt in the guest interrupt number space) and an
in-kernel source for that interrupt, ie, vhost and PCI pass-through
essentially.
Anything else is under qemu control. IE. MSIs or LSIs generated by
emulated devices are just normal interrupt that go through our ioctl to
trigger the in-kernel source with the same number.
I don't see any "routing" happening anywhere in that picture really. The
firmware calls done by the guest to change the target of interrupts
(which CPU/presentation controller to direct a given interrupt to) are
handled entirely in the kernel in platform specific code and update our
internal ICS state.
> >
> > I might just miss some subtleties here but so far I haven't been able to
> > figure out how to "shoehorn" our stuff in the very x86-centric existing
> > interfaces to the kernel APICs. In fact all that code is in a generic
> > location in kvm but is really x86/ia64 centric and the interfaces seem
> > to be as well.
>
> That's not true in general, though you surely find a lot of traces and
> still a few concrete x86 bits under virt/kvm.
Well, I haven't found anything in virt/kvm/irq_comm.c that was of any
use to us. Again, I might be sufferring from a major misunderstanding
here but as far as I can tell, the model is totally different. Besides,
that file has a hard coded list of what looks like completely x86
specific mappings between "GSI" and "interrupt numbers" (again I don't
understand completely the distinction and I don't think we have anything
like it on power).
Ben.
next prev parent reply other threads:[~2012-10-26 11:09 UTC|newest]
Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-14 0:04 [RFC PATCH 0/3] KVM: ARM: Get rid of hardcoded VGIC addresses Christoffer Dall
2012-10-14 0:04 ` [RFC PATCH 1/3] KVM: ARM: Introduce KVM_INIT_IRQCHIP ioctl Christoffer Dall
2012-10-17 20:21 ` Peter Maydell
2012-10-17 20:23 ` Christoffer Dall
2012-10-17 20:31 ` Peter Maydell
2012-10-17 20:39 ` Christoffer Dall
2012-10-18 12:20 ` Avi Kivity
2012-10-19 18:42 ` Christoffer Dall
2012-10-14 0:04 ` [RFC PATCH 2/3] KVM: ARM: Introduce KVM_SET_DEVICE_ADDRESS ioctl Christoffer Dall
2012-10-17 20:29 ` Peter Maydell
2012-10-19 18:46 ` Christoffer Dall
2012-10-19 20:24 ` Peter Maydell
2012-10-19 20:27 ` Christoffer Dall
2012-10-19 20:33 ` Christoffer Dall
2012-10-14 0:04 ` [RFC PATCH 3/3] KVM: ARM: Split KVM_CREATE_IRQCHIP and KVM_INIT_IRQCHIP Christoffer Dall
2012-10-18 11:15 ` Peter Maydell
2012-10-17 20:38 ` [kvmarm] [RFC PATCH 0/3] KVM: ARM: Get rid of hardcoded VGIC addresses Alexander Graf
2012-10-17 20:38 ` Alexander Graf
2012-10-17 20:39 ` Christoffer Dall
2012-10-17 20:39 ` Christoffer Dall
2012-10-17 21:19 ` Benjamin Herrenschmidt
2012-10-17 21:19 ` Benjamin Herrenschmidt
2012-10-17 22:10 ` Paul Mackerras
2012-10-17 22:10 ` Paul Mackerras
2012-10-17 23:58 ` Benjamin Herrenschmidt
2012-10-17 23:58 ` Benjamin Herrenschmidt
2012-10-18 13:48 ` Christoffer Dall
2012-10-18 13:48 ` Christoffer Dall
2012-10-18 13:49 ` Alexander Graf
2012-10-18 13:49 ` Alexander Graf
2012-10-18 15:25 ` Avi Kivity
2012-10-18 15:25 ` Avi Kivity
2012-10-23 10:48 ` Jan Kiszka
2012-10-23 10:48 ` Jan Kiszka
2012-10-23 10:52 ` Peter Maydell
2012-10-23 10:52 ` Peter Maydell
2012-10-23 11:00 ` Jan Kiszka
2012-10-23 11:00 ` Jan Kiszka
2012-10-23 11:04 ` Peter Maydell
2012-10-23 11:04 ` Peter Maydell
2012-10-23 11:08 ` Jan Kiszka
2012-10-23 11:08 ` Jan Kiszka
2012-10-24 0:50 ` Paul Mackerras
2012-10-24 0:50 ` Paul Mackerras
2012-10-25 11:57 ` Jan Kiszka
2012-10-25 11:57 ` Jan Kiszka
2012-10-25 16:14 ` Paolo Bonzini
2012-10-25 16:14 ` Paolo Bonzini
2012-10-25 16:32 ` Jan Kiszka
2012-10-25 16:32 ` Jan Kiszka
2012-10-25 18:27 ` Paolo Bonzini
2012-10-25 18:27 ` Paolo Bonzini
2012-10-25 19:40 ` Benjamin Herrenschmidt
2012-10-25 19:40 ` Benjamin Herrenschmidt
2012-10-26 9:58 ` Paolo Bonzini
2012-10-26 9:58 ` Paolo Bonzini
2012-10-26 10:09 ` Peter Maydell
2012-10-26 10:09 ` Peter Maydell
2012-10-26 10:15 ` Paolo Bonzini
2012-10-26 10:15 ` Paolo Bonzini
2012-10-26 10:22 ` Jan Kiszka
2012-10-26 10:22 ` Jan Kiszka
2012-10-26 10:44 ` Benjamin Herrenschmidt
2012-10-26 10:44 ` Benjamin Herrenschmidt
2012-10-26 11:00 ` Jan Kiszka
2012-10-26 11:00 ` Jan Kiszka
2012-10-26 11:09 ` Benjamin Herrenschmidt [this message]
2012-10-26 11:09 ` Benjamin Herrenschmidt
2012-10-26 11:57 ` Paolo Bonzini
2012-10-26 11:57 ` Paolo Bonzini
2012-10-26 12:08 ` Peter Maydell
2012-10-26 12:08 ` Peter Maydell
2012-10-26 12:41 ` Jan Kiszka
2012-10-26 12:41 ` Jan Kiszka
2012-10-26 20:21 ` Benjamin Herrenschmidt
2012-10-26 20:21 ` Benjamin Herrenschmidt
2012-10-26 11:17 ` Peter Maydell
2012-10-26 11:17 ` Peter Maydell
2012-10-26 11:39 ` Benjamin Herrenschmidt
2012-10-26 11:39 ` Benjamin Herrenschmidt
2012-10-26 12:39 ` Jan Kiszka
2012-10-26 12:39 ` Jan Kiszka
2012-10-26 20:45 ` Benjamin Herrenschmidt
2012-10-26 20:45 ` Benjamin Herrenschmidt
2012-10-26 22:03 ` Benjamin Herrenschmidt
2012-10-26 22:03 ` Benjamin Herrenschmidt
2012-10-27 8:06 ` Jan Kiszka
2012-10-27 8:06 ` Jan Kiszka
2012-10-27 10:01 ` Peter Maydell
2012-10-27 10:01 ` Peter Maydell
2012-10-28 22:19 ` Benjamin Herrenschmidt
2012-10-28 22:19 ` Benjamin Herrenschmidt
2012-10-26 10:37 ` Benjamin Herrenschmidt
2012-10-26 10:37 ` Benjamin Herrenschmidt
2012-10-26 10:40 ` Paolo Bonzini
2012-10-26 10:40 ` Paolo Bonzini
2012-10-26 10:47 ` Benjamin Herrenschmidt
2012-10-26 10:47 ` Benjamin Herrenschmidt
2012-10-26 11:47 ` Paolo Bonzini
2012-10-26 11:47 ` Paolo Bonzini
2012-10-25 19:39 ` Benjamin Herrenschmidt
2012-10-25 19:39 ` Benjamin Herrenschmidt
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=1351249794.12271.27.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=agraf@suse.de \
--cc=c.dall@virtualopensystems.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm-ppc@vger.kernel.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=paulus@samba.org \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.