From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM PMU virtualization Date: Fri, 26 Feb 2010 15:30:29 +0200 Message-ID: <4B87CCF5.6000209@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> <4B87C354.9020209@redhat.com> <20100226130656.GA2518@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jes Sorensen , 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]:27478 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936230Ab0BZNbV (ORCPT ); Fri, 26 Feb 2010 08:31:21 -0500 In-Reply-To: <20100226130656.GA2518@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/2010 03:06 PM, Ingo Molnar wrote: > >>> 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. >> > That's wrong. On some CPUs the host PMU can be used to say sample aspects of > another CPU, allowing statistical attacks to recover crypto keys. It can be > used to sample memory access patterns of another node. > > There's a good reason PMU configuration registers are privileged and there's > good value in only giving a certain sub-set to less privileged entities by > default. > Even if there were no security considerations, if the guest can observe host data in the pmu, it means the pmu is inaccurate. We should expose guest data only in the guest pmu. That's not difficult to do, you stop the pmu on exit and swap the counters on context switches. >> 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. >> > 'Full PMU' is not the granularity i find acceptable though: please do what i > suggested, event granularity allocation and scheduling. > > We are rehashing the whole 'perfmon versus perf events/counters' design > arguments again here really. > Scheduling at event granularity would be a good thing. However we need to be able to handle the guest using the full pmu. Note that scheduling is only needed if both the guest and host want the pmu at the same time - and that should be a rare case and not the one to optimize for. >>> 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. >> > That's precisely my point: the guest should obviously not get raw access to > the PMU. (except where it might matter to performance, such as RDPMC) > That's doable if all counters are steerable. IIRC some counters are fixed function, but I'm not certain about that. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.