Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753784AbcJNP2J (ORCPT <rfc822;w@1wt.eu>);
        Fri, 14 Oct 2016 11:28:09 -0400
Received: from mx1.redhat.com ([209.132.183.28]:39100 "EHLO mx1.redhat.com"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753372AbcJNP2C (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Fri, 14 Oct 2016 11:28:02 -0400
Subject: Re: aarch64 ACPI boot regressed by commit 7ba5f605f3a0 ("arm64/numa:
 remove the limitation that cpu0 must bind to node0")
To: Andrew Jones <drjones@redhat.com>,
        Zhen Lei <thunder.leizhen@huawei.com>,
        Will Deacon <will.deacon@arm.com>,
        Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
        Hanjun Guo <hanjun.guo@linaro.org>
References: <4a64cd93-5ead-aad6-1057-f42224d65b43@redhat.com>
 <20161014080524.4hm2b4p373r7rhel@hawk.localdomain>
 <04f22a79-301b-f05b-033d-c7a24c9f4084@redhat.com>
 <d26ea7ca-6b65-b3a6-591e-ab892f1815e7@redhat.com>
Cc: main kernel list <linux-kernel@vger.kernel.org>,
        linux-arm-kernel@lists.infradead.org,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        Shannon Zhao <shannon.zhao@linaro.org>, Wei Huang <wei@redhat.com>
From: Laszlo Ersek <lersek@redhat.com>
Message-ID: <b8b58d52-691c-11f0-2d26-a51e03430771@redhat.com>
Date: Fri, 14 Oct 2016 17:27:58 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <d26ea7ca-6b65-b3a6-591e-ab892f1815e7@redhat.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 14 Oct 2016 15:28:02 +0000 (UTC)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 953
Lines: 27

On 10/14/16 17:01, Laszlo Ersek wrote:

> Maybe the code I
> tried to analyze in this email was never *meant* to associate CPU#0 with
> any NUMA node at all (not even node 0); instead, other code -- for
> example code removed by 7ba5f605f3a0 -- was meant to perform that
> association.

Staring a bit more at the code, this looks very likely; in acpi_map_gic_cpu_interface() we have

> 	/* Check if GICC structure of boot CPU is available in the MADT */
> 	if (cpu_logical_map(0) == hwid) {
> 		if (bootcpu_valid) {
> 			pr_err("duplicate boot CPU MPIDR: 0x%llx in MADT\n",
> 			       hwid);
> 			return;
> 		}
> 		bootcpu_valid = true;
> 		return;
> 	}

which means that this callback function (for parsing the GICC structures in the MADT) expects to find the boot processor as well.

Upon finding the boot processor, we set bootcpu_valid to true, and that's it -- no association with any NUMA node, and no incrementing of "cpu_count".

Thanks
Laszlo