RE: [PATCH][2.4] generic support for systems with more than 8 CP

[Protasevich, Natalie]

+	/*
+	 * Switch to Physical destination mode in case of generic
+	 * more than 8 CPU system, which has xAPIC support
+	 */
+#define FLAT_APIC_CPU_MAX	8
+	if ((clustered_apic_mode == CLUSTERED_APIC_NONE) &&
+	    (xapic_support) &&
+	    (num_processors > FLAT_APIC_CPU_MAX)) {
+		clustered_apic_mode = CLUSTERED_APIC_XAPIC;
+		apic_broadcast_id = APIC_BROADCAST_ID_XAPIC;
+		int_dest_addr_mode = APIC_DEST_PHYSICAL;
+		int_delivery_mode = dest_Fixed;
+		esr_disable = 1;
+	}
+#endif
+

Venkatesh,
I could not find the definition for CLUSTERED_APIC_NONE. Is this an attempt
to set up the clustered mode right in case if it was not compiled with
CLUSTERED_..._XAPIC on the system with > 8 cpu?

>There is already some code in base that does this. For NUMAQ specifically
>this check happens and clustered mode is selected for APIC. My patch has
this 
>additinal check (after the initial IBM OEM check), for non-NUMAQ systems
with 
>more than 8 CPUs and xAPIC support. These systems can not work with the 
>default flat addressing mode. So, this patch sets up such systems in
physical 
>mode.

In the systems like ES7000, all CPU (up to 32) and IO-APICs have 8-bit
hard-wired ID's according to their topological position. Therefore, the
apic_broadcast_id be has to be 0xFF (like summit's, I guess), and modes
should be clustered logical for Cascades, clustered physical for xAPIC. The
IO-APIC lines are programmed with the broadcast ID/lowest priority for
Cascades, and boot CPU ID/XTPR flag/Lowest priority for Fosters/Gallatins.
This is pretty much the only choices we have. If this is not what the patch
allows to do, we need a last chance architectural hook to be able to
accommodate our stuff.

Thanks,
--Natalie

>Thanks,
>-Venkatesh