linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
To: Jes Sorensen <Jes.Sorensen@redhat.com>
Cc: Avi Kivity <avi@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
	kvm@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Fr??d??ric Weisbecker <fweisbec@gmail.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Lin Ming <ming.m.lin@intel.com>,
	Sheng Yang <sheng@linux.intel.com>,
	Marcelo Tosatti <mtosatti@redhat.com>,
	oerg Roedel <joro@8bytes.org>, Gleb Natapov <gleb@redhat.com>,
	Zachary Amsden <zamsden@redhat.com>,
	zhiteng.huang@intel.com, tim.c.chen@intel.com,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [PATCH V2 1/5] ara virt interface of perf to support kvm guest os statistics collection in guest os
Date: Wed, 23 Jun 2010 09:13:44 +0800	[thread overview]
Message-ID: <1277255624.2096.728.camel@ymzhang.sh.intel.com> (raw)
In-Reply-To: <4C206D3E.3060506@redhat.com>

On Tue, 2010-06-22 at 09:58 +0200, Jes Sorensen wrote:
> On 06/22/10 09:47, Zhang, Yanmin wrote:
> > On Tue, 2010-06-22 at 09:14 +0200, Jes Sorensen wrote:
> >> On 06/22/10 03:49, Zhang, Yanmin wrote:
> >>> On Mon, 2010-06-21 at 14:45 +0300, Avi Kivity wrote:
> >>> So I think above discussion is around how to expose PMU hardware to guest os. I will
> >>> also check this method after the para virt interface is done.
> >>
> >> You should be able to expose the counters as read-only to the guest. KVM
> >> allows you to specify whether or not a guest has read, write or
> >> read/write access. If you allowed read access of the counters that would
> >> safe a fair bit of hyper calls.
> > Thanks. KVM is good in register access permission configuration. But things are not so
> > simple like that if we consider real running environment. Host kernel might schedule
> > guest os vcpu thread to other cpus, or other non-kvm processes might preempt the vcpu
> > thread on this cpu.
> > 
> > To support such capability you said, we have to implement the direct exposition of PMU
> > hardware to guest os eventually.
> 
> If the guest is rescheduled to another CPU, or you get a preemption, you
> have a VMEXIT. The vcpu thread will not migrate while it is running, so
> you can handle it while the the VMEXIT is being serviced.
> 
> Exposing the counters read-only would save a lot of overhead for sure.
> >> Question is if it is safe to drop overflow support?
> > Not safe. One of PMU hardware design objectives is to use interrupt or NMI to notify
> > software when event counter overflows. Without overflow support, software need poll
> > the PMU registers looply. That is not good and consumes more cpu resources.
> 
> Here is an idea, how about having the overflow NMI in the host trigger a
> flag that causes the PMU register read to trap and get special handling?
> That way you could propagate the overflow back down to the guest.
That doesn't resolve the issue that guest os software has to poll register.



  reply	other threads:[~2010-06-23  1:13 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-21  9:31 [PATCH V2 1/5] ara virt interface of perf to support kvm guest os statistics collection in guest os Zhang, Yanmin
2010-06-21 11:45 ` Avi Kivity
2010-06-22  1:49   ` Zhang, Yanmin
2010-06-22  7:14     ` Jes Sorensen
2010-06-22  7:47       ` Zhang, Yanmin
2010-06-22  7:55         ` Peter Zijlstra
2010-06-22  8:00           ` Jes Sorensen
2010-06-22  9:29             ` Zhang, Yanmin
2010-06-22  9:31               ` Peter Zijlstra
2010-06-22  9:39                 ` Jes Sorensen
2010-06-22  9:46                   ` Peter Zijlstra
2010-06-22  9:53                     ` Avi Kivity
2010-06-22 10:02                       ` Peter Zijlstra
2010-06-22 10:06                         ` Avi Kivity
2010-06-22 10:10                           ` Peter Zijlstra
2010-06-22 11:01                             ` Avi Kivity
2010-06-22  7:58         ` Jes Sorensen
2010-06-23  1:13           ` Zhang, Yanmin [this message]
2010-06-23  8:15             ` Jes Sorensen
2010-06-22  8:59     ` Avi Kivity

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=1277255624.2096.728.camel@ymzhang.sh.intel.com \
    --to=yanmin_zhang@linux.intel.com \
    --cc=Jes.Sorensen@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=avi@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=gleb@redhat.com \
    --cc=gorcunov@gmail.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ming.m.lin@intel.com \
    --cc=mingo@elte.hu \
    --cc=mtosatti@redhat.com \
    --cc=sheng@linux.intel.com \
    --cc=tim.c.chen@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;
as well as URLs for NNTP newsgroup(s).