linux-kernel - Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 Feb 2008 13:25:18 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Yinghai Lu <Yinghai.Lu@....COM>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86_64: make amd quad core 8 socket system not be clustered_box

Yinghai Lu <Yinghai.Lu@....COM> writes:

> quad core 8 socket system will have apic id lifting.the apic id range could
> be [4, 0x23]. or [8, 0x27]. apic_is_clustered_box will think that need to three clusters
> and that is large than 2. So it is treated as clustered_box.
>
> and will get
>
> Marking TSC unstable due to TSCs unsynchronized
>
> even the CPUs have X86_FEATURE_CONSTANT_TSC set.
>
> this patch offset back the apic before get apic clusterid.
>
> or use dmi to get apic_is_clustered?

The clustered check is for Summit and es7000 systems
On 64bit systems it might be actually possible to trigger
this based on SLIT instead. But you'll need to check with
the IBM Summit/Unisys es7000 developers if that works or not

If you don't want to do that the safer way would be probably
the check if there are holes between the CPUs APIC numbers.
If yes then it's likely clustered mode. I think that would
be better than to disable it unconditionally for apic lifting
like your patches does.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/