From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jes Sorensen Subject: Re: KVM PMU virtualization Date: Fri, 26 Feb 2010 13:56:34 +0100 Message-ID: <4B87C502.1040208@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> <4B87B5DE.30503@redhat.com> <20100226120750.GA11578@elte.hu> <4B87BC74.7050207@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ingo Molnar , 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: Avi Kivity Return-path: Received: from mx1.redhat.com ([209.132.183.28]:18822 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935925Ab0BZM5S (ORCPT ); Fri, 26 Feb 2010 07:57:18 -0500 In-Reply-To: <4B87BC74.7050207@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/10 13:20, Avi Kivity wrote: > On 02/26/2010 02:07 PM, Ingo Molnar wrote: >> ... which is why i suggested the soft-PMU approach. > > Not sure I understand it completely. > > Do you mean to take the model specific host pmu events, and expose them > to the guest via trap'n'emulate? In that case we may as well assign the > host pmu to the guest if the host isn't using it, and avoid the traps. > > Do you mean to choose some older pmu and emulate it using whatever pmu > model the host has? I haven't checked, but aren't there mutually > exclusive events in every model pair? The closest thing would be the > architectural pmu thing. You cannot do this, as you say there is no guarantee that there are no overlaps, and the current host may have different counter sizes two which makes emulating it even more costly. The cpuid bits basically tells you which version of the counters are available, how many counters are there, word size of the counters and I believe there are bits also stating which optional features are available to be counted. > Or do you mean to define a new, kvm-specific pmu model and feed it off > the host pmu? In this case all the guests will need to be taught about > it, which raises the compatibility problem. Cannot be done in a reasonable manner due to the above. The key to all of this is that guests OSes, including that other OS, should be able to use the performance counters without needing special para virt drivers or other OS modifications. If we start requering that kind of stuff, the whole point of having the feature goes down the toilet. Cheers, Jes