From owner-p4-projects@FreeBSD.ORG Mon Apr 2 15:55:48 2007 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 04ACE16A409; Mon, 2 Apr 2007 15:55:48 +0000 (UTC) X-Original-To: perforce@freebsd.org Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B10CE16A403; Mon, 2 Apr 2007 15:55:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id 3532313C46C; Mon, 2 Apr 2007 15:55:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l32FtZFK086560; Mon, 2 Apr 2007 11:55:35 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Marcel Moolenaar Date: Mon, 2 Apr 2007 11:55:19 -0400 User-Agent: KMail/1.9.6 References: <200704012152.l31LqHuB022635@repoman.freebsd.org> <200704020915.03985.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704021155.21453.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Mon, 02 Apr 2007 11:55:35 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/2997/Mon Apr 2 06:19:52 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Marcel Moolenaar , Perforce Change Reviews Subject: Re: PERFORCE change 117140 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2007 15:55:48 -0000 On Monday 02 April 2007 11:22:09 am Marcel Moolenaar wrote: > > On Apr 2, 2007, at 6:15 AM, John Baldwin wrote: > > > On Sunday 01 April 2007 05:52:17 pm Marcel Moolenaar wrote: > >> http://perforce.freebsd.org/chv.cgi?CH=117140 > >> > >> Change 117140 by marcel@marcel_xcllnt on 2007/04/01 21:52:12 > >> > >> Create PCPU structures for all CPUs. Reduce dependency > >> on MAXCPU by allocating PCPU structures on demand. > >> > >> Affected files ... > >> > >> .. //depot/projects/powerpc/sys/powerpc/include/pcpu.h#6 edit > >> .. //depot/projects/powerpc/sys/powerpc/powerpc/machdep.c#8 edit > >> .. //depot/projects/powerpc/sys/powerpc/powerpc/mp_machdep.c#9 edit > >> .. //depot/projects/powerpc/sys/powerpc/powerpc/ofw_machdep.c#7 edit > >> > >> Differences ... > >> > >> ==== //depot/projects/powerpc/sys/powerpc/include/pcpu.h#6 (text > >> +ko) ==== > >> > >> @@ -40,6 +40,7 @@ > >> int pc_inside_intr; \ > >> struct pmap *pc_curpmap; /* current pmap */ \ > >> struct thread *pc_fputhread; /* current fpu user */ \ > >> + int pc_bsp:1; \ > > > > FYI, other places in MI code assume that CPU 0 (pc_cpuid) is the BSP. > > Not a problem so far, but it's probably better to eliminate that > assumption. If firmware is to select the BSP and there's no > requirement for it to select CPU0, then there will be situations > where it will not select CPU0. One such situation is when CPU0 > is disabled. It is used during shutdown so that we shutdown on the BSP. > For example, to analyze machine checks on on pluto1, I disabled CPU0 > and CPU1 in succession to see if one of the CPUs was the cause of the > MC. As such, CPU1 had to be the BSP when CPU0 was disabled. Luckily > pluto1 is only a dual-CPU machine, so that disabling a CPU also stops > SMP operation :-) FreeBSD CPU ID's != firmware CPU IDs. FreeBSD CPU ID's (pc_cpuid) are a logical CPU ID that the OS assigns, and I think it's ok for the OS to always give CPU 0 to the BSP. CPU ID's != local APIC ID's on x86 for example, nor are they identical to the CPU indices in the hwprb on Alpha. FreeBSD CPU ID's tend to not be sparse for example, because they are completely separate from firmware IDs. -- John Baldwin