From: Daniel J Blueman <daniel@numascale-asia.com>
To: Ingo Molnar <mingo@elte.hu>, Suresh Siddha <suresh.b.siddha@intel.com>
Cc: "H. Peter Anvin" <hpa@linux.intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, x86@kernel.org,
Steffen Persvold <sp@numascale.com>,
Yinghai Lu <yinghai@kernel.org>
Subject: x2APIC and many-APIC systems...
Date: Tue, 13 Mar 2012 17:29:41 +0800 [thread overview]
Message-ID: <4F5F1385.60406@numascale-asia.com> (raw)
Ingo, Suresh,
Commit a35fd28256e7736cc84af8931a16224f0bfaaf6c prevents x2APIC
structures being used from the ACPI MADT if the cores don't advertise
the x2APIC feature. Commit c284b42abadbb22083bfde24d308899c08d44ffa
prevents onlining cores with APIC ID >255 in non-x2APIC mode. Since
NumaChip/NumaConnect uses x2APIC structures to describe non-x2APIC
systems (AMD Opteron) with lots of APICs, we thus now can't boot all the
cores.
We are able to set the x2APIC bit in the processor feature flags, so get
caught by the second patch. Is there an appropriate approach to use in
these circumstances? Otherwise, would a patch that separates the APIC ID
handover and future x2APIC MSR access be appropriate?
Many thanks,
Daniel
--
Daniel J Blueman
Principal Software Engineer, Numascale Asia
next reply other threads:[~2012-03-13 9:29 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-13 9:29 Daniel J Blueman [this message]
2012-03-13 22:58 ` x2APIC and many-APIC systems Yinghai Lu
2012-03-13 23:16 ` Suresh Siddha
2012-03-14 7:17 ` [PATCH] Move APIC ID validity check into platform APIC code Daniel J Blueman
2012-03-14 11:27 ` [tip:x86/platform] x86/platform: " tip-bot for Daniel J Blueman
2012-03-14 17:58 ` [PATCH] " Yinghai Lu
2012-03-14 20:18 ` Steffen Persvold
2012-03-14 23:19 ` Yinghai Lu
2012-03-15 18:03 ` [PATCH] Use x2apic_supported() in the default_apic_id_valid() function Steffen Persvold
2012-03-15 20:23 ` Yinghai Lu
2012-03-15 21:21 ` Suresh Siddha
2012-03-15 22:34 ` Steffen Persvold
2012-03-15 22:58 ` Steffen Persvold
2012-03-15 23:04 ` Suresh Siddha
2012-03-15 23:17 ` Steffen Persvold
2012-03-15 23:33 ` Steffen Persvold
2012-03-15 23:44 ` Steffen Persvold
2012-03-16 0:07 ` [PATCH] Added separate apic_id_valid() functions for selected apic drivers Steffen Persvold
2012-03-16 0:13 ` Suresh Siddha
2012-03-16 0:57 ` Yinghai Lu
2012-03-16 6:45 ` Steffen Persvold
2012-03-16 2:08 ` [PATCH] Use x2apic_supported() in the default_apic_id_valid() function Yinghai Lu
2012-03-16 3:03 ` Yinghai Lu
2012-03-16 4:19 ` Yinghai Lu
2012-03-16 6:56 ` Steffen Persvold
2012-03-16 16:57 ` Yinghai Lu
2012-03-16 18:01 ` Suresh Siddha
2012-03-16 19:10 ` Yinghai Lu
2012-03-16 19:25 ` [PATCH REPOST] Added separate apic_id_valid() functions for selected apic drivers Steffen Persvold
2012-03-20 10:41 ` Steffen Persvold
2012-03-20 10:49 ` Ingo Molnar
2012-03-23 19:45 ` [tip:x86/urgent] x86/apic: Add " tip-bot for Steffen Persvold
2012-03-20 16:20 ` [PATCH 0/6] Improvements to Yinghai's x86 IOAPIC hotplug work Jiang Liu
2012-03-20 16:20 ` [PATCH 0/5] Improvements to Yinghai's IOAPIC hotplug work on x86 Jiang Liu
2012-03-20 16:20 ` [PATCH 1/6] x86,IRQ: Fix possible invalid memory access after IOAPIC hot-plugging Jiang Liu
2012-03-20 16:20 ` [PATCH 2/6] x86,IRQ: Mark unused entries in 'ioapics' array as free at startup Jiang Liu
2012-03-21 3:25 ` Yinghai Lu
2012-03-21 3:32 ` Jiang Liu
2012-03-21 14:56 ` Jiang Liu
2012-03-20 16:21 ` [PATCH 3/6] x86,IRQ: Enhance irq allocation policy for hot-added IOAPICs Jiang Liu
2012-03-20 16:21 ` [PATCH 4/6] x86,IRQ: split out function ioapic_setup_resource() Jiang Liu
2012-03-21 3:34 ` Yinghai Lu
2012-03-21 3:43 ` Jiang Liu
2012-03-20 16:21 ` [PATCH 5/6] x86,IRQ: Correctly manage MMIO resource used by IOAPIC when hot-plugging IOPAICs Jiang Liu
2012-03-20 16:21 ` [PATCH 6/6] x86,IRQ: Use memory barriers to protect searching side code Jiang Liu
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=4F5F1385.60406@numascale-asia.com \
--to=daniel@numascale-asia.com \
--cc=hpa@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sp@numascale.com \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yinghai@kernel.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.