From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: qemu-devel@nongnu.org,
Alex Williamson <alex.williamson@redhat.com>,
Alex Graf <agraf@suse.de>,
anthony@codemonkey.ws, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] [RFC PATCH] qemu spapr-pci: added IRQ list to PCIBus
Date: Thu, 17 May 2012 13:00:41 +1000 [thread overview]
Message-ID: <1337223641.30558.40.camel@pasglop> (raw)
In-Reply-To: <4FB45F8F.5000708@ozlabs.ru>
On Thu, 2012-05-17 at 12:16 +1000, Alexey Kardashevskiy wrote:
> > It actually can change dynamically on x86 due to acpi interrupt links
> > which allow the guest a generic way to select from a set of possible
> > interrupt routing schemes. And of course a chipset driver could twiddle
> > bits if it wanted as well. So, we really do need the update notifiers
> > from my tree that this patch drops.
>
>
> You mean notifiers like these: ioapic_add_gsi_eoi_notifier?
> I did not drop them, we need them so I implemented them for XICS interrupt controller.
So I haven't completely understood the problem, however:
.../...
> So it stores global IRQs in the config space but it really unclear who writes these _global_ numbers
> there. Is it the guest who allocates IRQs and writes the numbers into the config space so QEMU knows
> what pin is what IRQ? If so, I am wrong, you are right :)
So you can certainly not write our global irq numbers in the config
space, since the config space IRQ_LINE register is only 8 bits long
which means it's not long enough.
In general we don't use that register on ppc anyways, it's just a
storage, it should have no actual effect on HW.
The IRQ_PIN register however is important and needs to indicate
which of the 4 interrupt lines associated with the bus the
device will trigger, so we need to get that right especially
vs. swizzling performed by intermediary bridges.
Here, we can either show all the bridges to the guest (emulate
them is fine) and keep the original PIN numbers, or we need
to filter config space to change the PIN numbers seen by the
guest to match the lack of appropriate swizzling.
> >> If we do not want pci_get_irq to return global IRQ numbers than it makes more sense to keep using
> >> pins (A,B,C,D) plus some bus ID and not introduce any new numbers at all.
> > How does that solve the initial problem of getting the EOI?
>
> >> How can PCIBus::pci_get_irq() _callbacks_ be useful?
> > It indicates support? Thanks,
>
> Flag is enough :)
> Honestly when I see a "get", I am looking for a "put" in any form. And for powerpc it makes some
> sense as IRQ is set in QEMU, not from the guest.
Cheers,
Ben.
next prev parent reply other threads:[~2012-05-17 3:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-12 7:29 [Qemu-devel] [RFC PATCH] qemu spapr-pci: added IRQ list to PCIBus Alexey Kardashevskiy
2012-05-14 1:58 ` David Gibson
2012-05-14 4:21 ` Alexey Kardashevskiy
2012-05-16 20:39 ` Alex Williamson
2012-05-17 2:16 ` Alexey Kardashevskiy
2012-05-17 3:00 ` Benjamin Herrenschmidt [this message]
2012-05-17 3:38 ` Alex Williamson
2012-05-17 3:39 ` Alexey Kardashevskiy
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=1337223641.30558.40.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=alex.williamson@redhat.com \
--cc=anthony@codemonkey.ws \
--cc=kvm@vger.kernel.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).