From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 1/2] KVM: Fix race between nmi injection and enabling nmi window Date: Thu, 03 Feb 2011 17:15:18 +0200 Message-ID: <4D4AC686.8010509@redhat.com> References: <1296745369-12066-1-git-send-email-avi@redhat.com> <1296745369-12066-2-git-send-email-avi@redhat.com> <4D4AC5B5.5050504@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , "kvm@vger.kernel.org" , Joerg Roedel To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:18843 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755806Ab1BCPQP (ORCPT ); Thu, 3 Feb 2011 10:16:15 -0500 In-Reply-To: <4D4AC5B5.5050504@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/03/2011 05:11 PM, Jan Kiszka wrote: > On 2011-02-03 16:02, Avi Kivity wrote: > > The interrupt injection logic looks something like > > > > if an nmi is pending, and nmi injection allowed > > inject nmi > > if an nmi is pending > > request exit on nmi window > > > > the problem is that "nmi is pending" can be set asynchronously by > > the PIT; if it happens to fire between the two if statements, we > > will request an nmi window even though nmi injection is allowed. On > > SVM, this has disasterous results, since it causes eflags.TF to be > > set in random guest code. > > Good point. Fortunately never seen on production machines so far here > (we have very moderate NMI rates). I've never seen it either, except with ftrace enabled. I wonder what the connection is. > > > > The fix is simple; make nmi_pending asynchronous using the standard > > You mean synchronous, no? > Yes. > > vcpu->requests mechanism; this ensures the code above is completely > > synchronous wrt nmi_pending. > > -- error compiling committee.c: too many arguments to function