[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201004152208.08409.sheng@linux.intel.com>
Date: Thu, 15 Apr 2010 22:08:08 +0800
From: Sheng Yang <sheng@...ux.intel.com>
To: Avi Kivity <avi@...hat.com>
Cc: Joerg Roedel <joro@...tes.org>,
"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
Marcelo Tosatti <mtosatti@...hat.com>,
Jes Sorensen <Jes.Sorensen@...hat.com>,
Gleb Natapov <gleb@...hat.com>,
Zachary Amsden <zamsden@...hat.com>, zhiteng.huang@...el.com,
tim.c.chen@...el.com, Arnaldo Carvalho de Melo <acme@...radead.org>
Subject: Re: [PATCH V3] perf & kvm: Enhance perf to collect KVM guest
os statistics from host side
On Thursday 15 April 2010 18:44:15 Avi Kivity wrote:
> On 04/15/2010 01:40 PM, Joerg Roedel wrote:
> >> That means an NMI that happens outside guest code (for example, in the
> >> mmu, or during the exit itself) would be counted as if in guest code.
> >
> > Hmm, true. The same is true for an NMI that happens between VMSAVE and
> > STGI but that window is smaller. Anyway, I think we don't need the
> > busy-wait loop. The NMI should be executed at a well defined point and
> > we set the cpu_var back to NULL after that point.
>
> The point is not well defined. Considering there are already at least
> two implementations svm, I don't want to rely on implementation details.
After more investigating, I realized that I had interpreted the SDM wrong.
Sorry.
There is *no* risk with the original method of calling "int $2".
According to the SDM 24.1:
> The following bullets detail when architectural state is and is not updated
in response to VM exits:
[...]
> - An NMI causes subsequent NMIs to be blocked, but only after the VM exit
completes.
So the truth is, after NMI directly caused VMExit, the following NMIs would be
blocked, until encountered next "iret". So execute "int $2" is safe in
vmx_complete_interrupts(), no risk in causing nested NMI. And it would unblock
the following NMIs as well due to "iret" it executed.
So there is unnecessary to make change to avoid "potential nested NMI".
Sorry for the mistake and caused confusing.
--
regards
Yang, Sheng
>
> We could tune the position of the loop so that zero iterations are
> executed on the implementations we know about.
>
--
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