linux-kernel - Re: [PATCH] x86, acpi: Handle xapic/x2apic entries in MADT

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:	Tue, 14 Jul 2015 16:26:26 +0800
From:	Jiang Liu <jiang.liu@...ux.intel.com>
To:	Lukasz Anaczkowski <lukasz.anaczkowski@...el.com>,
	tglx@...utronix.de, mingo@...hat.com, hpa@...or.com,
	x86@...nel.org, jason@...edaemon.net
CC:	rjw@...ysocki.net, len.brown@...el.com, pavel@....cz,
	linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-acpi@...r.kernel.org
Subject: Re: [PATCH] x86, acpi: Handle xapic/x2apic entries in MADT

On 2015/7/14 16:06, Lukasz Anaczkowski wrote:
> This patch is based on work of "Yinghai Lu <yinghai@...nel.org>"
> previously published at https://lkml.org/lkml/2013/1/21/563.
> 
> In case when BIOS is populating MADT wiht both x2apic and local apic
> entries (as per ACPI spec), e.g. for Xeon Phi Knights Landing,
> kernel builds it's processor table in the following order:
> BSP, X2APIC, local APIC, resulting in processors on the same core
> are not separated by core count, i.e.
> 
> Core LCpu   ApicId    LCpu    ApicId     LCpu    ApicId    LCpu    ApicId
> 0    0 (  0 [0000]),   97 (  1 [0001]),  145 (  2 [0002]),  193 (  3 [0003])
> 1   50 (  4 [0004]),   98 (  5 [0005]),  146 (  6 [0006]),  194 (  7 [0007])
> 2   51 ( 16 [0010]),   99 ( 17 [0011]),  147 ( 18 [0012]),  195 ( 19 [0013])
> 3   52 ( 20 [0014]),  100 ( 21 [0015]),  148 ( 22 [0016]),  196 ( 23 [0017])
> 4   53 ( 24 [0018]),  101 ( 25 [0019]),  149 ( 26 [001a]),  197 ( 27 [001b])
> 5   54 ( 28 [001c]),  102 ( 29 [001d]),  150 ( 30 [001e]),  198 ( 31 [001f])
> ...
> 
> Please note, how LCpu are mixed for physical cores (Core).
> 
> This patch fixes this behavior and resulting assignment is
> consistent with other Xeon processors, i.e.
> 
> Core LCpu   ApicId    LCpu    ApicId     LCpu    ApicId    LCpu    ApicId
> 0    0 (  0 [0000]),   72 (  1 [0001]),  144 (  2 [0002]),  216 (  3 [0003])
> 1    1 (  4 [0004]),   73 (  5 [0005]),  145 (  6 [0006]),  217 (  7 [0007])
> 2    2 (  8 [0008]),   74 (  9 [0009]),  146 ( 10 [000a]),  218 ( 11 [000b])
> 3    3 ( 12 [000c]),   75 ( 13 [000d]),  147 ( 14 [000e]),  219 ( 15 [000f])
> 4    4 ( 16 [0010]),   76 ( 17 [0011]),  148 ( 18 [0012]),  220 ( 19 [0013])
> 5    5 ( 20 [0014]),   77 ( 21 [0015]),  149 ( 22 [0016]),  221 ( 23 [0017])
> ...
> 
> Signed-off-by: Lukasz Anaczkowski <lukasz.anaczkowski@...el.com>
Hi Lukasz,
	I have some concerns here about "maxcpus" and "nox2apic" kernel
parameters. Say "maxcpus=72 nox2apic" is specified, user may get
less than 72 CPUs with you patch applied. Original code will try to
only all xapic CPUs before trying x2apic CPUs, so "maxcpus" doesn't
conflict with "nox2apic".
Thanks!
Gerry
--
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/