From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755663Ab2CGPuq (ORCPT ); Wed, 7 Mar 2012 10:50:46 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26643 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753979Ab2CGPup (ORCPT ); Wed, 7 Mar 2012 10:50:45 -0500 Date: Wed, 7 Mar 2012 10:50:18 -0500 From: Vivek Goyal To: Fernando Luis =?iso-8859-1?Q?V=E1zquez?= Cao Cc: "Eric W. Biederman" , Don Zickus , linux-tip-commits@vger.kernel.org, Yinghai Lu , mingo@elte.hu, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com, akpm@linux-foundation.org, torvalds@linux-foundation.org, tglx@linutronix.de Subject: Re: [tip:x86/debug] x86/kdump: No need to disable ioapic/ lapic in crash path Message-ID: <20120307155018.GA13430@redhat.com> References: <20120216215603.GH9751@redhat.com> <20120217195430.GO9751@redhat.com> <20120220151419.GU9751@redhat.com> <20120221135934.GF26998@redhat.com> <4F573E1C.2060909@oss.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4F573E1C.2060909@oss.ntt.co.jp> 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 Wed, Mar 07, 2012 at 07:53:16PM +0900, Fernando Luis Vázquez Cao wrote: > On 03/01/2012 08:19 AM, Eric W. Biederman wrote: > > >Don Zickus writes: > >>It probably is, except I never hacked on idt code before and my assembly > >>isn't that good. I have been trying to find examples to copy from to give > >>it a try. So far I was using early_idt_handlers with early_printk to see > >>if I could capture some printk messages while jumping from the first > >>kernel to the second kernel (when the other early_idt_handlers would kick > >>in for the second kernel). > >> > >>Tips? Better examples? > >That is a particularly good example. When I took a quick look earlier > >that is the first place we reload the idt in the kernel boot so that is > >one of two places that needs to be modified. > > Hi Eric, Don > > Sorry for chiming in so late. > > We run into the same NMI problems and wrote some patches that tackle > the kernel boot side of things. They have been extensively tested using > qemu-kvm and things seem to be working as expected (after receiving an > early NMI the kernel continues without problem; after the iret there is no > stack corruption or register corruption). What happens if NMI happens while we are still in purgatory code? Thanks Vivek