From: ebiederm@xmission.com (Eric W. Biederman) To: Jeremy Fitzhardinge <jeremy@goop.org> Cc: 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: Tue, 16 Jun 2009 22:10:45 -0700 [thread overview] Message-ID: <m1eitjv416.fsf@fess.ebiederm.org> (raw) In-Reply-To: <4A37F4AE.5050902@goop.org> (Jeremy Fitzhardinge's message of "Tue\, 16 Jun 2009 12\:38\:22 -0700") Jeremy Fitzhardinge <jeremy@goop.org> writes: > The only effect of this patch is to parse the I/O APIC parts of the MADT even if > it skips the local APIC parts; it causes no change in behaviour in normal > circumstances (unless you actually have a physical machine with ACPI and I/O > APICs but CPUs with no local APICs, which is guess is possible in principle). You allow getting to places like apic->setup_apic_routing without going through prerequisites like generic_bigsmp_probe(). > Can you give an example of how mechanism and policy are mixed? In what ways > could it break? Would you agree to a patch which attempts to decouple policy > and mechanism to solve these problems? I would agree with a patch that decouples the parts you need. Something that makes it possible to call apci_parse_madt_lapic_entries without calling the rest of the code sounds reasonable. Given that ia64 already has a separate path calling into acpi I'm not certain there is much truly useful code that can be shared. Getting the BIOS bug workarounds seems reasonable. It would be good to see at least a rough draft of where you are going. So the whole picture can be clear. Right now. I don't think there is anything in anything in arch/x86/kernel/apic/* arch/x86/kernel/smpboot.c that is usable for xen. As for mixing mechanism and policy besides the cpu_has_apic tests we have generic_bigsmp_probe, the calling of apic_setup_apic_routing. The code that depends on the CONFIG_X86_LOCAL_APIC define. There are also deep assumptions in the code like default_setup_apic_routing. That tests the number of local apics and uses that to decide on how to setup the ioapics. Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman) To: Jeremy Fitzhardinge <jeremy@goop.org> 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> Subject: Re: [PATCH RFC] x86/acpi: don't ignore I/O APICs just because there's no local APIC Date: Tue, 16 Jun 2009 22:10:45 -0700 [thread overview] Message-ID: <m1eitjv416.fsf@fess.ebiederm.org> (raw) In-Reply-To: <4A37F4AE.5050902@goop.org> (Jeremy Fitzhardinge's message of "Tue\, 16 Jun 2009 12\:38\:22 -0700") Jeremy Fitzhardinge <jeremy@goop.org> writes: > The only effect of this patch is to parse the I/O APIC parts of the MADT even if > it skips the local APIC parts; it causes no change in behaviour in normal > circumstances (unless you actually have a physical machine with ACPI and I/O > APICs but CPUs with no local APICs, which is guess is possible in principle). You allow getting to places like apic->setup_apic_routing without going through prerequisites like generic_bigsmp_probe(). > Can you give an example of how mechanism and policy are mixed? In what ways > could it break? Would you agree to a patch which attempts to decouple policy > and mechanism to solve these problems? I would agree with a patch that decouples the parts you need. Something that makes it possible to call apci_parse_madt_lapic_entries without calling the rest of the code sounds reasonable. Given that ia64 already has a separate path calling into acpi I'm not certain there is much truly useful code that can be shared. Getting the BIOS bug workarounds seems reasonable. It would be good to see at least a rough draft of where you are going. So the whole picture can be clear. Right now. I don't think there is anything in anything in arch/x86/kernel/apic/* arch/x86/kernel/smpboot.c that is usable for xen. As for mixing mechanism and policy besides the cpu_has_apic tests we have generic_bigsmp_probe, the calling of apic_setup_apic_routing. The code that depends on the CONFIG_X86_LOCAL_APIC define. There are also deep assumptions in the code like default_setup_apic_routing. That tests the number of local apics and uses that to decide on how to setup the ioapics. Eric
next prev parent reply other threads:[~2009-06-17 5:11 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 [this message] 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 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=m1eitjv416.fsf@fess.ebiederm.org \ --to=ebiederm@xmission.com \ --cc=hpa@zytor.com \ --cc=jeremy@goop.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.