From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jes Sorensen Subject: Re: KVM PMU virtualization Date: Fri, 26 Feb 2010 14:31:03 +0100 Message-ID: <4B87CD17.1040301@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=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]:19199 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936209Ab0BZNbs (ORCPT ); Fri, 26 Feb 2010 08:31:48 -0500 In-Reply-To: <20100226130656.GA2518@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/10 14:06, Ingo Molnar wrote: > > * Jes Sorensen wrote: >> 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. > > It's not that many MSR accesses. Well it's more than enough to double the number of MSRs KVM has to track on switches. >> 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. If a PMU can really count stuff on another CPU, then we shouldn't allow PMU access to any application at all. It's more than just a KVM guest vs a KVM guest issue then, but also a thread to thread issue. My idea was obviously not to expose host timings to a guest. Save the counters when a guest exits, and reload them when it's restarted. Not just when switching to another task, but also when entering KVM, to avoid the guest seeing overhead spent within KVM. >> 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. As I wrote earlier, at that level we have to do it all emulated. In this case, providing any of this to a guest seems to be a waste of time since the interface will cost way too much in trapping back and forth and you have contention with the very limited resources in the PMU with just 5 counters to pick from on Core2. The guest PMU will think it's running on top of real hardware, and scaling/estimating numbers like the perf_event.c code does today, except that it will be using already scaled and estimated numbers for it's calculations. Application users will have little use for this. >> 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) Well either you allow access to the PMU or you don't. If you allow direct access to the PMU counters, but not the control registers, you have to specify the counter sizes to match that of the host, making it impossible to really emulate core2 on a non core2 architecture etc. Jes