From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from terminus.zytor.com ([198.137.202.10]) by bombadil.infradead.org with esmtps (Exim 4.68 #1 (Red Hat Linux)) id 1JMqpn-0005Je-JZ for kexec@lists.infradead.org; Wed, 06 Feb 2008 20:25:38 +0000 Message-ID: <47AA16CA.6000003@zytor.com> Date: Wed, 06 Feb 2008 12:21:30 -0800 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: [PATCH], issue EOI to APIC prior to calling crash_kexec in die_nmi path References: <20080206192555.GA24910@hmsendeavour.rdu.redhat.com> <20080206194040.GA11886@redhat.com> <20080206201223.GA25183@hmsendeavour.rdu.redhat.com> In-Reply-To: <20080206201223.GA25183@hmsendeavour.rdu.redhat.com> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kexec-bounces@lists.infradead.org Errors-To: kexec-bounces+dwmw2=infradead.org+dwmw2=infradead.org@lists.infradead.org To: Neil Horman Cc: Neil Horman , kexec@lists.infradead.org, linux-kernel@vger.kernel.org, mingo@redhat.com, tglx@linutronix.de, Vivek Goyal Neil Horman wrote: > Can an APIC accept an NMI while already handling an NMI? I didn't think they > would interrupt one another, but rather, pend until such time as the previous > NMI was cleared The CPU certainly won't (there is a hidden flag that's cleared on IRET which disables NMI; it's possible to re-enable NMI by executing a dummy IRET inside the NMI handler.) -hpa _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758257AbYBFU1Q (ORCPT ); Wed, 6 Feb 2008 15:27:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1755384AbYBFU1B (ORCPT ); Wed, 6 Feb 2008 15:27:01 -0500 Received: from terminus.zytor.com ([198.137.202.10]:46961 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755004AbYBFU1A (ORCPT ); Wed, 6 Feb 2008 15:27:00 -0500 Message-ID: <47AA16CA.6000003@zytor.com> Date: Wed, 06 Feb 2008 12:21:30 -0800 From: "H. Peter Anvin" User-Agent: Thunderbird 2.0.0.9 (X11/20071115) MIME-Version: 1.0 To: Neil Horman CC: Vivek Goyal , Neil Horman , tglx@linutronix.de, mingo@redhat.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH], issue EOI to APIC prior to calling crash_kexec in die_nmi path References: <20080206192555.GA24910@hmsendeavour.rdu.redhat.com> <20080206194040.GA11886@redhat.com> <20080206201223.GA25183@hmsendeavour.rdu.redhat.com> In-Reply-To: <20080206201223.GA25183@hmsendeavour.rdu.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Neil Horman wrote: > Can an APIC accept an NMI while already handling an NMI? I didn't think they > would interrupt one another, but rather, pend until such time as the previous > NMI was cleared The CPU certainly won't (there is a hidden flag that's cleared on IRET which disables NMI; it's possible to re-enable NMI by executing a dummy IRET inside the NMI handler.) -hpa