From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@redhat.com>
Subject: Re: VMX: Host NMI triggering on NMI vmexit
Date: Fri, 19 Sep 2008 15:37:37 -0700
Message-ID: <48D429B1.6090105@redhat.com>
References: <48CF97F1.9090004@siemens.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "Yang, Sheng" <sheng.yang@intel.com>,
	kvm-devel <kvm@vger.kernel.org>
To: Jan Kiszka <jan.kiszka@siemens.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from il.qumranet.com ([212.179.150.194]:32209 "EHLO il.qumranet.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1751503AbYISWhf (ORCPT <rfc822;kvm@vger.kernel.org>);
	Fri, 19 Sep 2008 18:37:35 -0400
In-Reply-To: <48CF97F1.9090004@siemens.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

Jan Kiszka wrote:
> Sheng,
>
> out of curiosity: vmx_vcpu_run invokes 'int $2' to trigger a host NMI if
> the VM exited due to an external NMI event. According to Intel specs I
> have, software-triggered NMIs do not block hardware NMIs. So are we
> facing the risk to receive another NMI while running the first handler?
> Or will the VM be left with the hardware blocking logic armed? Or does
> Linux not care about NMI handler re-entrance?
>   

All good questions.  Usually this doesn't happen since NMI sources are
far apart (oprofile, watchdog).

Maybe the answer is to generate the local nmi via an IPI-to-self command
to the local apic.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.