From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762376Ab2EQWx2 (ORCPT ); Thu, 17 May 2012 18:53:28 -0400 Received: from terminus.zytor.com ([198.137.202.10]:38241 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757211Ab2EQWx0 (ORCPT ); Thu, 17 May 2012 18:53:26 -0400 Message-ID: <4FB58143.8060007@zytor.com> Date: Thu, 17 May 2012 15:52:51 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Ingo Molnar 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() 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> In-Reply-To: <20120514121725.GA10840@gmail.com> X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.