From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752228AbbJMLzo (ORCPT ); Tue, 13 Oct 2015 07:55:44 -0400 Received: from mail7.hitachi.co.jp ([133.145.228.42]:36202 "EHLO mail7.hitachi.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752768AbbJMLzP (ORCPT ); Tue, 13 Oct 2015 07:55:15 -0400 From: =?utf-8?B?5rKz5ZCI6Iux5a6PIC8gS0FXQUnvvIxISURFSElSTw==?= To: "'Borislav Petkov'" CC: "'Peter Zijlstra'" , Jonathan Corbet , 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 Thread-Topic: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option Thread-Index: AQHQ94oh6MYtIS0XDEWuNE+WtK4xp55UZ/AAgAGEPrD//7JggIAAnR0g//+I5YCAAK/fMP//dpIAAC+EULD//+ALgP/7JpJQgAmbhQD//2DHAIAAvT+A//K/J7A= Date: Tue, 13 Oct 2015 11:55:10 +0000 Message-ID: <04EAB7311EE43145B2D3536183D1A844549B7264@GSjpTKYDCembx31.service.hitachi.net> References: <20151001062733.GL2881@worktop.programming.kicks-ass.net> <04EAB7311EE43145B2D3536183D1A8445499D30D@GSjpTKYDCembx31.service.hitachi.net> <20151001084335.GA3764@pd.tnic> <04EAB7311EE43145B2D3536183D1A8445499DB92@GSjpTKYDCembx31.service.hitachi.net> <20151001110110.GA3544@pd.tnic> <04EAB7311EE43145B2D3536183D1A8445499ED83@GSjpTKYDCembx31.service.hitachi.net> <20151002074721.GA16538@pd.tnic> <04EAB7311EE43145B2D3536183D1A844549A4557@GSjpTKYDCembx31.service.hitachi.net> <20151005082704.GA23259@nazgul.tnic> <04EAB7311EE43145B2D3536183D1A844549A48D3@GSjpTKYDCembx31.service.hitachi.net> <20151005101431.GC23259@nazgul.tnic> In-Reply-To: <20151005101431.GC23259@nazgul.tnic> Accept-Language: ja-JP, en-US Content-Language: ja-JP X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.198.220.44] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id t9DBtnhR025880 Hello, Boris Sorry for the late reply. > On Mon, Oct 05, 2015 at 09:21:02AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote: > > So, the problem for you is that "noextnmi" option is visible and effective > > in the first kernel, isn't it? > > No, such an option shouldn't exist at all. You should be passing > information *in* *a* *different* *manner* to the kdump kernel - not with > a kernel command line option. Sorry, I couldn't find out the reason why I shouldn't use cmdline option. It doesn't need new user I/F to inform the 1st kernel about masking/unmasking external NMI in the 2nd kernel, doesn't need new data passing infrastructure, and is easy to configure that. Also, "elfcorehdr" and "disable_cpu_apicid" have already been introduced as cmdline options for dump capture kernel. This means the cmdline option approach would be mostly acceptable. > I get the feeling I'm starting to sound like a broken record on this > mail thread... :-( > > One other thing we could probably try to do is use boot_params which > is, IIUC, passed to the second kernel. So we can add another bit to > boot_params.hdr.loadflags or so and use that. Or something similar. I think using boot_params would be worse than ELF header approach. It needs to reserve boot_params bits for all boot loaders. Regards, Hidehiro Kawai Hitachi, Ltd. Research & Development Group {.n++%ݶw{.n+{G{ayʇڙ,jfhz_(階ݢj"mG?&~iOzv^m ?I