All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Jes Sorensen <Jes.Sorensen@redhat.com>
Cc: Avi Kivity <avi@redhat.com>, Joerg Roedel <joro@8bytes.org>,
	KVM General <kvm@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Zachary Amsden <zamsden@redhat.com>,
	Gleb Natapov <gleb@redhat.com>,
	ming.m.lin@intel.com, "Zhang,
	Yanmin" <yanmin_zhang@linux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Arjan van de Ven <arjan@infradead.org>,
	Fr??d??ric Weisbecker <fweisbec@gmail.com>,
	Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: Re: KVM PMU virtualization
Date: Fri, 26 Feb 2010 12:42:17 +0100	[thread overview]
Message-ID: <20100226114217.GI7463@elte.hu> (raw)
In-Reply-To: <4B87AF44.9090702@redhat.com>


* Jes Sorensen <Jes.Sorensen@redhat.com> wrote:

> On 02/26/10 11:44, Ingo Molnar wrote:
> >Direct access to counters is not something that is a big issue. [ Given that i
> >sometimes can see KVM redraw the screen of a guest OS real-time i doubt this
> >is the biggest of performance challenges right now ;-) ]
> >
> >By far the biggest instrumentation issue is:
> >
> >  - availability
> >  - usability
> >  - flexibility
> >
> >Exposing the raw hw is a step backwards in many regards. The same way we dont
> >want to expose chipsets to the guest to allow them to do RAS. The same way we
> >dont want to expose most raw PCI devices to guest in general, but have all
> >these virt driver abstractions.
> 
> I have to say I disagree on that. When you run perfmon on a system, it is 
> normally to measure a specific application. You want to see accurate numbers 
> for cache misses, mul instructions or whatever else is selected.

You can still get those. You can even enable RDPMC access and avoid VM exits.

What you _cannot_ do is to 'steal' the PMU and just give it to the guest.

> Emulating the PMU rather than using the real one, makes the numbers far less 
> useful. The most useful way to provide PMU support in a guest is to expose 
> the real PMU and let the guest OS program it.

Firstly, an emulated PMU was only the second-tier option i suggested. By far 
the best approach is native API to the host regarding performance events and 
good guest side integration.

Secondly, the PMU cannot be 'given' to the guest in the general case. Those 
are privileged registers. They can expose sensitive host execution details, 
etc. etc. So if you emulate a PMU you have to exit out of most PMU accesses 
anyway for a secure solution. (RDPMC can still be supported, but in close 
cooperation with the host)

> We can do this in a reasonable way today, if we allow to take the PMU away 
> from the host, and only let guests access it when it's in use. [...]

You get my sure-fire NAK for that kind of crap though. Interfering with the 
host PMU and stealing it, is not a technical approach that has acceptable 
quality.

You need to integrate it properly so that host PMU functionality still works 
fine. (Within hardware constraints)

	Ingo

  reply	other threads:[~2010-02-26 11:42 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
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 [this message]
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=20100226114217.GI7463@elte.hu \
    --to=mingo@elte.hu \
    --cc=Jes.Sorensen@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=arjan@infradead.org \
    --cc=avi@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=gleb@redhat.com \
    --cc=hpa@zytor.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=ming.m.lin@intel.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=yanmin_zhang@linux.intel.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.