From: Jeremy Fitzhardinge <jeremy@goop.org> To: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Len Brown <lenb@kernel.org>, Ingo Molnar <mingo@redhat.com>, Thomas Gleixner <tglx@linutronix.de>, "H. Peter Anvin" <hpa@zytor.com>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Xen-devel <xen-devel@lists.xensource.com> Subject: Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC Date: Thu, 18 Jun 2009 15:33:40 -0700 [thread overview] Message-ID: <4A3AC0C4.6060508@goop.org> (raw) In-Reply-To: <m1vdmtgtt2.fsf@fess.ebiederm.org> On 06/18/09 13:39, Eric W. Biederman wrote: >> Well, if acpi_pci_irq_lookup() and friends return the right things >> without having parsed the MADT and set up the secondary state, then we >> should be fine either way. >> >> acpi_irq_model gets tested in all sorts of random places, so I wonder if >> we'll need to set it to ACPI_IRQ_MODEL_IOAPIC (or something else?) to >> make things work properly. >> > > And this is where things get interesting. Xen strictly speaking has > already made that decision. Unless you support non APIC mode it > should always be ACPI_IRQ_MODEL_IOAPIC. > We could decide by fiat to not support non-APIC machines (which is more or less the case), but they do happen to work at the moment; Gerd even has one and provided fixes to make it work. (Ditto non-ACPI, though they're commonly related.) > But Xen runs the hardware so Xen knows, and Xen should be running > all of the acpi and what not to make it happen. > There are two separate issues: 1. If we intercept interrupt routing at the pcibios_pci_irq_enable level, will anything in the kernel care about the state of its acpi_irq_model variable? At first glance it *shouldn't* care, because its just handing the whole problem off to Xen. 2. Xen has no AML interpreter, so its use of ACPI is limited to parsing tables. It looks like we'll need to set acpi_irq_model appropriately and then get acpi_bus_init_irq() to run. (Related to this is making sure any chipset configuration that happens in the depths of the DSDT does in fact happen.) >> Hm, and principle we just get the SCI gsi from the FADT, but there's all >> that other mucking about with it in the MADT processing... Wonder what >> needs to happen there... >> > > Good question. What does the domU case do? > DomU doesn't know or care about ACPI at all. There's no reason for it to get any kind of ACPI event. J
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org> To: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Xen-devel <xen-devel@lists.xensource.com>, the arch/x86 maintainers <x86@kernel.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, Thomas Gleixner <tglx@linutronix.de>, Len Brown <lenb@kernel.org> Subject: Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC Date: Thu, 18 Jun 2009 15:33:40 -0700 [thread overview] Message-ID: <4A3AC0C4.6060508@goop.org> (raw) In-Reply-To: <m1vdmtgtt2.fsf@fess.ebiederm.org> On 06/18/09 13:39, Eric W. Biederman wrote: >> Well, if acpi_pci_irq_lookup() and friends return the right things >> without having parsed the MADT and set up the secondary state, then we >> should be fine either way. >> >> acpi_irq_model gets tested in all sorts of random places, so I wonder if >> we'll need to set it to ACPI_IRQ_MODEL_IOAPIC (or something else?) to >> make things work properly. >> > > And this is where things get interesting. Xen strictly speaking has > already made that decision. Unless you support non APIC mode it > should always be ACPI_IRQ_MODEL_IOAPIC. > We could decide by fiat to not support non-APIC machines (which is more or less the case), but they do happen to work at the moment; Gerd even has one and provided fixes to make it work. (Ditto non-ACPI, though they're commonly related.) > But Xen runs the hardware so Xen knows, and Xen should be running > all of the acpi and what not to make it happen. > There are two separate issues: 1. If we intercept interrupt routing at the pcibios_pci_irq_enable level, will anything in the kernel care about the state of its acpi_irq_model variable? At first glance it *shouldn't* care, because its just handing the whole problem off to Xen. 2. Xen has no AML interpreter, so its use of ACPI is limited to parsing tables. It looks like we'll need to set acpi_irq_model appropriately and then get acpi_bus_init_irq() to run. (Related to this is making sure any chipset configuration that happens in the depths of the DSDT does in fact happen.) >> Hm, and principle we just get the SCI gsi from the FADT, but there's all >> that other mucking about with it in the MADT processing... Wonder what >> needs to happen there... >> > > Good question. What does the domU case do? > DomU doesn't know or care about ACPI at all. There's no reason for it to get any kind of ACPI event. J
next prev parent reply other threads:[~2009-06-18 22:33 UTC|newest] Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-06-12 18:22 [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC Jeremy Fitzhardinge 2009-06-12 18:22 ` Jeremy Fitzhardinge 2009-06-12 18:28 ` Alan Cox 2009-06-12 18:28 ` Alan Cox 2009-06-12 18:33 ` Jeremy Fitzhardinge 2009-06-12 18:33 ` Jeremy Fitzhardinge 2009-06-12 20:11 ` Cyrill Gorcunov 2009-06-15 2:01 ` Jeremy Fitzhardinge 2009-06-12 20:35 ` Eric W. Biederman 2009-06-12 20:35 ` Eric W. Biederman 2009-06-15 2:06 ` Jeremy Fitzhardinge 2009-06-15 10:47 ` Eric W. Biederman 2009-06-15 10:47 ` Eric W. Biederman 2009-06-15 20:49 ` Jeremy Fitzhardinge 2009-06-15 20:49 ` Jeremy Fitzhardinge 2009-06-15 21:58 ` Eric W. Biederman 2009-06-15 21:58 ` Eric W. Biederman 2009-06-16 19:38 ` Jeremy Fitzhardinge 2009-06-16 19:38 ` Jeremy Fitzhardinge 2009-06-17 5:10 ` Eric W. Biederman 2009-06-17 5:10 ` Eric W. Biederman 2009-06-17 12:02 ` Eric W. Biederman 2009-06-17 12:02 ` Eric W. Biederman 2009-06-17 17:32 ` Jeremy Fitzhardinge 2009-06-17 17:32 ` Jeremy Fitzhardinge 2009-06-18 2:58 ` Eric W. Biederman 2009-06-18 2:58 ` Eric W. Biederman 2009-06-18 19:34 ` Jeremy Fitzhardinge 2009-06-18 19:34 ` Jeremy Fitzhardinge 2009-06-18 20:28 ` Eric W. Biederman 2009-06-18 21:09 ` Jeremy Fitzhardinge 2009-06-18 21:09 ` Jeremy Fitzhardinge 2009-06-19 1:38 ` Eric W. Biederman 2009-06-19 1:38 ` Eric W. Biederman 2009-06-19 3:10 ` [Xen-devel] " Jiang, Yunhong 2009-06-19 3:10 ` Jiang, Yunhong 2009-06-18 12:26 ` Eric W. Biederman 2009-06-15 10:51 ` Eric W. Biederman 2009-06-15 10:51 ` Eric W. Biederman 2009-06-18 16:08 ` Len Brown 2009-06-18 19:14 ` Jeremy Fitzhardinge 2009-06-18 19:14 ` Jeremy Fitzhardinge 2009-06-18 19:27 ` Eric W. Biederman 2009-06-18 19:48 ` Jeremy Fitzhardinge 2009-06-18 19:48 ` Jeremy Fitzhardinge 2009-06-18 20:39 ` Eric W. Biederman 2009-06-18 22:33 ` Jeremy Fitzhardinge [this message] 2009-06-18 22:33 ` Jeremy Fitzhardinge 2009-06-19 2:42 ` Eric W. Biederman 2009-06-19 2:42 ` Eric W. Biederman 2009-06-19 19:58 ` Jeremy Fitzhardinge 2009-06-19 19:58 ` Jeremy Fitzhardinge 2009-06-19 23:44 ` [Xen-devel] " Nakajima, Jun 2009-06-19 23:44 ` Nakajima, Jun 2009-06-20 7:39 ` [Xen-devel] " Keir Fraser 2009-06-20 7:39 ` Keir Fraser 2009-06-20 8:21 ` [Xen-devel] " Eric W. Biederman 2009-06-20 8:21 ` Eric W. Biederman 2009-06-20 8:57 ` [Xen-devel] " Tian, Kevin 2009-06-20 8:57 ` Tian, Kevin 2009-06-20 10:22 ` [Xen-devel] " Keir Fraser 2009-06-20 10:22 ` Keir Fraser 2009-06-20 8:18 ` [Xen-devel] " Eric W. Biederman 2009-06-20 8:18 ` Eric W. Biederman 2009-06-19 5:32 ` Yinghai Lu 2009-06-19 5:32 ` Yinghai Lu 2009-06-19 5:50 ` Eric W. Biederman 2009-06-19 5:50 ` Eric W. Biederman 2009-06-19 7:52 ` [Xen-devel] Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs justbecause " Jan Beulich 2009-06-19 7:52 ` Jan Beulich 2009-06-19 8:16 ` [Xen-devel] " Eric W. Biederman 2009-06-19 8:16 ` Eric W. Biederman 2009-06-20 3:58 ` [Xen-devel] " Yinghai Lu 2009-06-20 3:58 ` Yinghai Lu 2009-06-20 5:40 ` [Xen-devel] " Eric W. Biederman 2009-06-20 5:40 ` Eric W. Biederman 2009-06-20 5:58 ` [Xen-devel] " Yinghai Lu 2009-06-20 5:58 ` Yinghai Lu 2009-06-18 22:51 ` [PATCH RFC] x86/acpi: don't ignore I/O APICs just because " Maciej W. Rozycki
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=4A3AC0C4.6060508@goop.org \ --to=jeremy@goop.org \ --cc=ebiederm@xmission.com \ --cc=hpa@zytor.com \ --cc=lenb@kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=tglx@linutronix.de \ --cc=x86@kernel.org \ --cc=xen-devel@lists.xensource.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: linkBe 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.