From owner-svn-src-head@freebsd.org Tue May 31 20:10:13 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B67CB58BC7; Tue, 31 May 2016 20:10:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E17C61809; Tue, 31 May 2016 20:10:12 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 01802B989; Tue, 31 May 2016 16:10:12 -0400 (EDT) From: John Baldwin To: Andrew Turner Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r301070 - head/sys/arm64/arm64 Date: Tue, 31 May 2016 12:48:48 -0700 Message-ID: <2110242.ihAnphvYLg@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <201605311845.u4VIjqJC046383@repo.freebsd.org> References: <201605311845.u4VIjqJC046383@repo.freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 31 May 2016 16:10:12 -0400 (EDT) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 20:10:13 -0000 On Tuesday, May 31, 2016 06:45:52 PM Andrew Turner wrote: > Author: andrew > Date: Tue May 31 18:45:52 2016 > New Revision: 301070 > URL: https://svnweb.freebsd.org/changeset/base/301070 > > Log: > Allow the kernel to boot on a CPU where the devicetree has numbered it with > a non-zero ID. To do this we increment the cpuid of any CPUs with a smaller > devicetree ID by one to stop them conflicting with the boot CPU. > > Obtained from: ABT Systems Ltd > Sponsored by: The FreeBSD Foundation It's a bit more friendly if you can have FreeBSD CPU IDs still represent the topology of the system if possible. On x86 we don't always boot from CPU 0 either (in fact, it's an election system so that the APIC ID of the BSP can vary from boot to boot). What we do however, is add CPUs from the same core, then package first after the BSP and then add remaining CPUs as we normally would. For x86, the first thread in a package is always chosen as the BSP, so this is implemented by starting at the APIC ID of the BSP and assigning CPU IDs to increasing APIC IDs and eventually wrapping back around to APIC ID 0 to add CPUs from "earlier" packages if we did not boot from package 0. However, this means that if you have a system with dual quad-core CPUs, CPUs 0-3 are always one package and 4-7 are always the other, regardless of which package is used for booting. Initially the x86 code did not do that but just skipped over the BSP when adding APs (so something similar I think to what you've done here), but that meant that when the second package won the boot-time election, CPUs 0,5-7 were on one package and 1-4 were on another package. -- John Baldwin