From: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
Jes Sorensen <Jes.Sorensen@redhat.com>,
KVM General <kvm@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Avi Kivity <avi@redhat.com>, Zachary Amsden <zamsden@redhat.com>,
Gleb Natapov <gleb@redhat.com>,
ming.m.lin@intel.com
Subject: Re: KVM PMU virtualization
Date: Fri, 26 Feb 2010 10:52:37 +0800 [thread overview]
Message-ID: <1267152757.1726.79.camel@localhost> (raw)
In-Reply-To: <20100225162631.GA21920@elte.hu>
On Thu, 2010-02-25 at 17:26 +0100, Ingo Molnar wrote:
> * Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> > Jes Sorensen wrote:
> > > Hi,
> > >
> > > It looks like several of us have been looking at how to use the PMU
> > > for virtualization. Rather than continuing to have discussions in
> > > smaller groups, I think it is a good idea we move it to the mailing
> > > lists to see what we can share and avoid duplicate efforts.
> > >
> > > There are really two separate things to handle:
> > >
> > > 1) Add support to perf to allow it to monitor a KVM guest from the
> > > host.
> > >
> > > 2) Allow guests access to the PMU (or an emulated PMU), making it
> > > possible to run perf on applications running within the guest.
> > >
> > > I know some of you have been looking at 1) and I am currently working
> > > on 2). I have been looking at various approaches, including whether it
> > > is feasible to share the PMU between the host and multiple guests. For
> > > now I am going to focus on allowing one guest to take control of the
> > > PMU, then later hopefully adding support for multiplexing it between
> > > multiple guests.
> >
> > Given that perf can apply the PMU to individual host tasks, I don't see
> > fundamental problems multiplexing it between individual guests (which can
> > then internally multiplex it again).
>
> In terms of how to expose it to guests, a 'soft PMU' might be a usable
> approach. Although to Linux guests you could expose much more functionality
> and an non-PMU-limited number of instrumentation events, via a more
> intelligent interface.
>
> But note that in terms of handling it on the host side the PMU approach is not
> acceptable: instead it should map to proper perf_events, not try to muck with
> the PMU itself.
>
> That, besides integrating properly with perf usage on the host, will also
> allow interesting 'PMU' features on guests: you could set up the host side to
> trace block IO requests (or VM exits) for example, and expose that as 'PMC
> #0' on the guest side.
So virtualization becomes non-transparent to guest os? I know virtio is an
optimization on guest side.
next prev parent reply other threads:[~2010-02-26 2:50 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-25 15:04 KVM PMU virtualization Jes Sorensen
2010-02-25 15:44 ` Jan Kiszka
2010-02-25 16:26 ` Ingo Molnar
2010-02-26 2:52 ` Zhang, Yanmin [this message]
2010-02-26 8:45 ` Ingo Molnar
2010-02-26 11:03 ` Jes Sorensen
2010-02-25 17:34 ` Joerg Roedel
2010-02-26 2:55 ` Zhang, Yanmin
2010-02-26 8:51 ` Joerg Roedel
2010-02-26 9:17 ` Ingo Molnar
2010-02-26 10:42 ` Joerg Roedel
2010-02-26 10:56 ` Ingo Molnar
2010-03-02 7:09 ` Zhang, Yanmin
2010-03-02 9:36 ` Ingo Molnar
2010-03-03 3:32 ` Zhang, Yanmin
2010-03-03 9:27 ` Zhang, Yanmin
2010-03-03 10:13 ` Peter Zijlstra
2010-03-04 0:52 ` Zhang, Yanmin
2010-03-03 10:15 ` Peter Zijlstra
2010-03-04 1:00 ` Zhang, Yanmin
2010-03-10 9:29 ` Zhang, Yanmin
2010-03-02 9:57 ` Peter Zijlstra
2010-02-26 8:42 ` Ingo Molnar
2010-02-26 9:46 ` Avi Kivity
2010-02-26 10:39 ` Joerg Roedel
2010-02-26 10:46 ` Ingo Molnar
2010-02-26 10:51 ` Avi Kivity
2010-02-26 11:06 ` Joerg Roedel
2010-02-26 11:18 ` Jes Sorensen
2010-02-26 11:24 ` Ingo Molnar
2010-02-26 11:25 ` Jes Sorensen
2010-02-26 11:20 ` Ingo Molnar
2010-02-26 10:44 ` Ingo Molnar
2010-02-26 11:16 ` Avi Kivity
2010-02-26 11:26 ` Ingo Molnar
2010-02-26 11:47 ` Avi Kivity
2010-02-26 11:23 ` Jes Sorensen
2010-02-26 11:42 ` Ingo Molnar
2010-02-26 11:51 ` Avi Kivity
2010-02-26 12:07 ` Ingo Molnar
2010-02-26 12:20 ` Avi Kivity
2010-02-26 12:38 ` Ingo Molnar
2010-02-26 13:04 ` Avi Kivity
2010-02-26 13:13 ` Jes Sorensen
2010-02-26 13:27 ` Ingo Molnar
2010-02-26 13:33 ` Avi Kivity
2010-02-26 14:07 ` Jes Sorensen
2010-02-26 14:11 ` Avi Kivity
2010-02-26 13:18 ` Ingo Molnar
2010-02-26 13:34 ` Jes Sorensen
2010-02-26 12:56 ` Jes Sorensen
2010-02-26 13:31 ` Ingo Molnar
2010-02-26 13:37 ` Jes Sorensen
2010-02-26 13:55 ` Avi Kivity
2010-02-26 14:27 ` Peter Zijlstra
2010-02-26 14:54 ` Avi Kivity
2010-02-26 15:08 ` Peter Zijlstra
2010-02-26 15:11 ` Avi Kivity
2010-02-26 15:18 ` Peter Zijlstra
2010-02-26 15:55 ` Peter Zijlstra
2010-02-26 16:06 ` Avi Kivity
2010-03-01 19:03 ` Zachary Amsden
2010-03-01 18:54 ` Zachary Amsden
2010-02-26 13:40 ` Avi Kivity
2010-02-26 14:01 ` Ingo Molnar
2010-02-26 14:22 ` Avi Kivity
2010-02-26 14:37 ` Ingo Molnar
2010-02-26 16:03 ` Avi Kivity
2010-02-26 16:07 ` Avi Kivity
2010-02-26 13:28 ` Peter Zijlstra
2010-02-26 13:44 ` Avi Kivity
2010-02-26 13:51 ` Jes Sorensen
2010-02-26 14:42 ` Peter Zijlstra
2010-03-08 18:14 ` Avi Kivity
2010-02-26 12:49 ` Jes Sorensen
2010-02-26 13:06 ` Ingo Molnar
2010-02-26 13:30 ` Avi Kivity
2010-02-26 13:32 ` Jes Sorensen
2010-02-26 13:44 ` Ingo Molnar
2010-02-26 13:53 ` Avi Kivity
2010-02-26 14:12 ` Ingo Molnar
2010-02-26 14:53 ` Avi Kivity
2010-02-26 15:14 ` Peter Zijlstra
2010-02-28 16:34 ` Joerg Roedel
2010-02-28 16:31 ` Joerg Roedel
2010-02-28 16:11 ` Joerg Roedel
2010-03-01 8:39 ` Ingo Molnar
2010-03-01 8:58 ` Joerg Roedel
2010-03-01 9:04 ` Ingo Molnar
2010-03-01 8:44 ` Ingo Molnar
2010-03-01 11:11 ` Joerg Roedel
2010-03-01 17:17 ` Peter Zijlstra
2010-03-01 18:36 ` Joerg Roedel
2010-03-08 10:15 ` Avi Kivity
2010-02-26 14:49 ` Peter Zijlstra
2010-02-26 14:50 ` Peter Zijlstra
2010-02-26 13:31 ` Jes Sorensen
2010-03-01 17:22 ` Zachary Amsden
2010-02-26 11:01 ` Jes Sorensen
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=1267152757.1726.79.camel@localhost \
--to=yanmin_zhang@linux.intel.com \
--cc=Jes.Sorensen@redhat.com \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=ming.m.lin@intel.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=zamsden@redhat.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