From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932324AbbJ0JGf (ORCPT ); Tue, 27 Oct 2015 05:06:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54010 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932095AbbJ0JGc (ORCPT ); Tue, 27 Oct 2015 05:06:32 -0400 Date: Tue, 27 Oct 2015 17:06:27 +0800 From: "'Baoquan He'" To: =?utf-8?B?5rKz5ZCI6Iux5a6PIC8gS0FXQUnvvIxISURFSElSTw==?= Cc: Jonathan Corbet , Peter Zijlstra , Ingo Molnar , "Eric W. Biederman" , "H. Peter Anvin" , Andrew Morton , Thomas Gleixner , Vivek Goyal , "linux-doc@vger.kernel.org" , "x86@kernel.org" , "kexec@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Michal Hocko , Ingo Molnar , =?utf-8?B?5bmz5p2+6ZuF5bezIC8gSElSQU1BVFXvvIxNQVNBTUk=?= Subject: Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option Message-ID: <20151027090627.GA29587@dhcp-128-28.nay.redhat.com> References: <20150925112803.4258.94241.stgit@softrs> <20150925112811.4258.54494.stgit@softrs> <20151027084622.GA5141@dhcp-128-28.nay.redhat.com> <04EAB7311EE43145B2D3536183D1A844549DC280@GSjpTKYDCembx31.service.hitachi.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <04EAB7311EE43145B2D3536183D1A844549DC280@GSjpTKYDCembx31.service.hitachi.net> 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 On 10/27/15 at 09:01am, 河合英宏 / KAWAI,HIDEHIRO wrote: > Hi, > > > I just have a look at this thread. I am wondering why we don't use > > existing is_kdump_kernel() directly to disable external NMI if it's > > in kdump kernel. Then no need to introduce another boot option "noextnmi" > > which is used only for kdump kernel. > > As I stated in another mail, there is a case where we don't want to > mask external NMIs in the second kernel. So, we need some > configurable way. Please see the following quotation. Got it. Thanks for telling. > > > We souldn't enable this feature silently. Some users wouldn't like > > to enable this feature. For example, a user enables a watchdog timer > > which raises an external NMI when the counter is not reset for a > > specific duration. Then, the second kernel hangs up while saving > > crash dump, and NMI is delivered to the CPU. The kernel gets panic > > due to the NMI, prints some information to the display and serial > > console, and then automatically reboot. In this case, users don't > > want to block external NMIs. > > Regards, > > Hidehiro Kawai > Hitachi, Ltd. Research & Development Group > >