From mboxrd@z Thu Jan  1 00:00:00 1970
From: Joerg Roedel <joerg.roedel@amd.com>
Subject: Re: [PATCH 1/8] KVM: SVM: Fix nested nmi handling
Date: Fri, 23 Apr 2010 16:51:20 +0200
Message-ID: <20100423145120.GL31537@amd.com>
References: <1271932394-13968-1-git-send-email-joerg.roedel@amd.com>
 <1271932394-13968-2-git-send-email-joerg.roedel@amd.com>
 <622FCBB5-826D-4392-A521-7E395507398B@suse.de>
 <20100423141355.GD31537@amd.com>
 <85D89C34-806C-4376-89BA-5BFD413F5396@suse.de>
 <20100423142258.GG31537@amd.com>
 <013159C3-277C-447C-B64B-D2196AF851F9@suse.de>
 <20100423143159.GJ31537@amd.com>
 <768234E2-FF02-42AC-B04C-00D98B19B1C0@suse.de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: Avi Kivity <avi@redhat.com>, Marcelo Tosatti <mtosatti@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
To: Alexander Graf <agraf@suse.de>
Return-path: <kvm-owner@vger.kernel.org>
Received: from va3ehsobe002.messaging.microsoft.com ([216.32.180.12]:47722
	"EHLO VA3EHSOBE002.bigfish.com" rhost-flags-OK-OK-OK-FAIL)
	by vger.kernel.org with ESMTP id S1754115Ab0DWOvs (ORCPT
	<rfc822;kvm@vger.kernel.org>); Fri, 23 Apr 2010 10:51:48 -0400
Content-Disposition: inline
In-Reply-To: <768234E2-FF02-42AC-B04C-00D98B19B1C0@suse.de>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

On Fri, Apr 23, 2010 at 04:42:52PM +0200, Alexander Graf wrote:
> 
> On 23.04.2010, at 16:31, Joerg Roedel wrote:
> 
> > On Fri, Apr 23, 2010 at 04:24:54PM +0200, Alexander Graf wrote:
> >> 
> >> On 23.04.2010, at 16:22, Joerg Roedel wrote:
> > 
> >>> No, nested_svm_nmi runs in atomic context where we can't emulate a
> >>> vmexit. We set exit_required and emulate the vmexit later.
> >> 
> >> So we modify the L2 rflags and then trigger a #vmexit, leaving the l2
> >> state broken?
> > 
> > No, the rflags are changed in enable_nmi_window which isn't called when
> > we run nested and the nested hypervisor intercepts nmi. So it only runs
> > in the !nested case where it can't corrupt L2 state.
> 
> Last time I checked the code enable_nmi_window was the function
> triggering the #vmexit,

Yes, thats the bug which this patch fixes :-)

>so it should run in that exact scenario. If what you say is true, where
>do we #vmexit instead then?

After setting exit_required we run into svm.c:svm_vcpu_run. There the
exit_required flag is checked and if set, the function immediatly
returns without doing a vmrun. A few cycles later we run into
svm.c:handle_exit() where at the beginning exit_required is checked, and
if set the vmexit is emulated.

	Joerg