public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Sheng Yang <sheng@linux.intel.com>
To: Avi Kivity <avi@redhat.com>
Cc: Joerg Roedel <joro@8bytes.org>,
	"Zhang, Yanmin" <yanmin_zhang@linux.intel.com>,
	Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	Marcelo Tosatti <mtosatti@redhat.com>,
	Jes Sorensen <Jes.Sorensen@redhat.com>,
	Gleb Natapov <gleb@redhat.com>,
	Zachary Amsden <zamsden@redhat.com>,
	zhiteng.huang@intel.com, tim.c.chen@intel.com,
	Arnaldo Carvalho de Melo <acme@infradead.org>
Subject: Re: [PATCH V3] perf & kvm: Enhance perf to collect KVM guest os	statistics from host side
Date: Thu, 15 Apr 2010 22:08:08 +0800	[thread overview]
Message-ID: <201004152208.08409.sheng@linux.intel.com> (raw)
In-Reply-To: <4BC6EDFF.3000702@redhat.com>

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.
> 

  reply	other threads:[~2010-04-15 14:08 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-14  9:06 [PATCH V3] perf & kvm: Enhance perf to collect KVM guest os statistics from host side Zhang, Yanmin
2010-04-14  9:20 ` Avi Kivity
2010-04-14  9:43   ` Sheng Yang
2010-04-14  9:57     ` Avi Kivity
2010-04-14 10:14       ` Sheng Yang
2010-04-14 10:19         ` Avi Kivity
2010-04-14 10:27           ` Sheng Yang
2010-04-14 10:33             ` Avi Kivity
2010-04-14 10:36               ` Sheng Yang
2010-04-14 10:43   ` Ingo Molnar
2010-04-14 11:17     ` Avi Kivity
2010-04-15  1:05   ` Zhang, Yanmin
2010-04-15  8:05     ` Avi Kivity
2010-04-15  8:58       ` Zhang, Yanmin
2010-04-15  9:04         ` oerg Roedel
2010-04-15  9:09           ` Avi Kivity
2010-04-15  9:44             ` oerg Roedel
2010-04-15  9:48               ` Avi Kivity
2010-04-15 10:40                 ` Joerg Roedel
2010-04-15 10:44                   ` Avi Kivity
2010-04-15 14:08                     ` Sheng Yang [this message]
2010-04-17 18:12                       ` Avi Kivity
2010-04-19  8:25                         ` Avi Kivity
2010-04-20  3:32                           ` Sheng Yang
2010-04-20  9:38                             ` Avi Kivity
2010-04-15  8:58       ` Zhang, Yanmin
2010-04-15  1:05   ` Zhang, Yanmin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201004152208.08409.sheng@linux.intel.com \
    --to=sheng@linux.intel.com \
    --cc=Jes.Sorensen@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@infradead.org \
    --cc=avi@redhat.com \
    --cc=gleb@redhat.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=mtosatti@redhat.com \
    --cc=tim.c.chen@intel.com \
    --cc=yanmin_zhang@linux.intel.com \
    --cc=zamsden@redhat.com \
    --cc=zhiteng.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox