Date: Mon, 25 Dec 2017 10:47:46 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Alexandru Chirvasitu <achirvasub@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        kernel list <linux-kernel@vger.kernel.org>,
        Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
        Brian Gerst <brgerst@gmail.com>, Denys Vlasenko <dvlasenk@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Josh Poimboeuf <jpoimboe@redhat.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Steven Rostedt <rostedt@goodmis.org>
Subject: Re: PROBLEM: consolidated IDT invalidation causes kexec to reboot
Message-ID: <20171225094746.bcbmqqyjiaioo7lh@gmail.com>
References: <20171224014415.GA5663@chirva-void>
 <CA+55aFypaeWzKh=wmwdw0PmMsVyP98hts5doC7CMtAH4095KTA@mail.gmail.com>
 <20171224072832.GA959@chirva-void>
 <20171224112817.4itmll6ru5i45t7n@gmail.com>
 <20171224152715.GA1506@chirva-void>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171224152715.GA1506@chirva-void>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1068
Lines: 32


* Alexandru Chirvasitu <achirvasub@gmail.com> wrote:

> The first attachment is the config I initially used last night after
> that second patch (removing 'local' etc.).
> 
> As you guessed, all four options are set, hence the name of the file
> (ending in '-y'). The other config I'm attaching was treated as you
> lay out (2-config-n).
> 
> I used the '-n' config to compile two kernels just now:
> 
> (a) e802a51, that same first commit giving me trouble.
> 
> The changes made no difference to kexec behaviour: with the e802a51
> kernel calling kexec boot directly with -e and triggering a panic both
> kick off a full reboot, though the crash kernel registers as loaded.
> 
> (b) the kernel in the branch I made last night, with the set_idt kexec
> (for good measure, I thought I might as well do this one too).
> 
> No difference here either: the crash dump kernel boots fine both ways
> (directly and upon intentional crashing).

Thanks for all the info!

Detailed analysis from me (or Thomas) will have to wait after the Christmas 
hollidays.

Thanks,

	Ingo