From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761272Ab2ERGqL (ORCPT ); Fri, 18 May 2012 02:46:11 -0400 Received: from mail-wi0-f178.google.com ([209.85.212.178]:40481 "EHLO mail-wi0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757393Ab2ERGqI (ORCPT ); Fri, 18 May 2012 02:46:08 -0400 Date: Fri, 18 May 2012 08:46:01 +0200 From: Ingo Molnar To: "H. Peter Anvin" Cc: Tony Luck , Thomas Gleixner , Fenghua Yu , Ingo Molnar , Linus Torvalds , Andrew Morton , Asit K Mallick , Arjan Dan De Ven , Suresh B Siddha , Len Brown , "Srivatssa S. Bhat" , Randy Dunlap , Chen Gong , linux-kernel , linux-pm , x86 , Peter Zijlstra Subject: Re: [PATCH v6 04/12] x86/smpboot.c: Don't offline CPU0 if any irq can not be migrated out of it and remove CPU0 check in smp_callin() Message-ID: <20120518064601.GC429@gmail.com> References: <1336666614-21090-1-git-send-email-fenghua.yu@intel.com> <1336666614-21090-5-git-send-email-fenghua.yu@intel.com> <20120514121725.GA10840@gmail.com> <4FB58143.8060007@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FB58143.8060007@zytor.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * H. Peter Anvin wrote: > On 05/14/2012 05:17 AM, Ingo Molnar wrote: > > > > * Tony Luck wrote: > > > >> Biggest code impact of that is the extra code to bring cpu0 > >> back online using NMI instead of INIT. We can't use INIT > >> because if cpu0 gets one, it just resets the whole machine :-( > >> But obviously we'd like to avoid special cases where there is > >> a sane way to do so. > > > > Could we just standardize on NMI bringup during regular bootup? > > > > The first instance has to be SIPI because you can't give the > CPU an NMI without the IDT being setup. We *could* assume > that the processor is parked in real mode with the valid > real-mode IDT set up (in which case the vector at physical > address 8 applies) but that seems to assume a lot from the > BIOS for little gain. In particular I suspect that UEFI-based > BIOSes may very well park the CPU in protected or long mode. Ok, fair enough. Thanks, Ingo