linux-kernel - Re: [PATCH 2/3] Add multi-node boot support

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]

Message-ID: <4ED9199A.3060108@numascale-asia.com>
Date:	Fri, 02 Dec 2011 18:31:54 +0000
From:	Daniel J Blueman <daniel@...ascale-asia.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Steffen Persvold <sp@...ascale.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	x86@...nel.org
Subject: Re: [PATCH 2/3] Add multi-node boot support

On 27/10/2011 12:38, Ingo Molnar wrote:
> * Steffen Persvold<sp@...ascale.com>  wrote:
>
>>> If it's absolutely needed then add a proper quirk handler instead
>>> of polluting the generic code.
>> We wanted to reuse as much of the generic AMD code as possible, but
>> it's tricky because most of that code is based around a single HT
>> fabric design, whereas a NumaChip based systems consists of several
>> HT fabrics connected together thus you will have identical
>> NorthBridge IDs (0-7) etc. shared between all systems.
>>
>> How would you suggest we add a quirk handler for it ?
> So what we want on NumaChip systems is for the node ID in the BIOS
> SRAT table to override the node ID that is read from the hardware,
> right?
>
> Instead of making it a is_numachip_system() thing it would be better
> to detect that the two do not match, and override it if the platform
> says that we should override it - and warn about the mismatch
> otherwise.
>
> Whether to override could be a new srat_override() function in the
> x86_init structure or so.
>
> Thomas, Peter, what do you think?

I've attached the updated patch series to show this approach. Tested 
against 3.2-rc3 with and without Numaconnect on x86-64 and includes 
updates from all previous feedback.

Since the struct x86_init is marked __init, and srat_detect_node() is 
marked __cpuinit, would be it better to add an x86_cpu_init structure 
with appropriate annotation or otherwise?

Thanks,
   Daniel

-- 
Daniel J Blueman
Principal Software Engineer, Numascale Asia


View attachment "0001-Make-flat_init_apic_ldr_available.patch" of type "text/x-patch" (1461 bytes)

View attachment "0002-x86_init-core-numbering.patch" of type "text/x-patch" (2043 bytes)

View attachment "0003-NumaChip-support.patch" of type "text/x-patch" (16355 bytes)