From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jes Sorensen Subject: Re: KVM PMU virtualization Date: Fri, 26 Feb 2010 13:49:24 +0100 Message-ID: <4B87C354.9020209@redhat.com> References: <4B86917C.4070102@redhat.com> <20100225173423.GB4246@8bytes.org> <20100226084241.GF15885@elte.hu> <4B87987A.2020302@redhat.com> <20100226104437.GB7463@elte.hu> <4B87AF44.9090702@redhat.com> <20100226114217.GI7463@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , Joerg Roedel , KVM General , Peter Zijlstra , Zachary Amsden , Gleb Natapov , ming.m.lin@intel.com, "Zhang, Yanmin" , Peter Zijlstra , Thomas Gleixner , "H. Peter Anvin" , Arjan van de Ven , Fr??d??ric Weisbecker , Arnaldo Carvalho de Melo To: Ingo Molnar Return-path: Received: from mx1.redhat.com ([209.132.183.28]:63863 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935882Ab0BZMva (ORCPT ); Fri, 26 Feb 2010 07:51:30 -0500 In-Reply-To: <20100226114217.GI7463@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/10 12:42, Ingo Molnar wrote: > > * Jes Sorensen wrote: >> 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. Well you cannot steal the PMU without collaborating with perf_event.c, but thats quite feasible. Sharing the PMU between the guest and the host is very costly and guarantees incorrect results in the host. Unless you completely emulate the PMU by faking it and then allocating PMU counters one by one at the host level. However that means trapping a lot of MSR access. > 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) There is nothing secret in the host PMU, and it's easy to clear out the counters before passing them off to the guest. >> 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. Having an allocation scheme and sharing it with the host, is a perfectly legitimate and very clean way to do it. Once it's given to the guest, the host knows not to touch it until it's been released again. > You need to integrate it properly so that host PMU functionality still works > fine. (Within hardware constraints) Well with the hardware currently available, there is no such thing as clean sharing between the host and the guest. It cannot be done without messing up the host measurements, which effectively renders measuring at the host side useless while a guest is allowed access to the PMU. Jes