[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100423145120.GL31537@amd.com>
Date: Fri, 23 Apr 2010 16:51:20 +0200
From: Joerg Roedel <joerg.roedel@....com>
To: Alexander Graf <agraf@...e.de>
CC: Avi Kivity <avi@...hat.com>, Marcelo Tosatti <mtosatti@...hat.com>,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/8] KVM: SVM: Fix nested nmi handling
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists