From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM PMU virtualization Date: Fri, 26 Feb 2010 15:40:09 +0200 Message-ID: <4B87CF39.4080801@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> <20100226133149.GA23422@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]:41136 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936237Ab0BZNkp (ORCPT ); Fri, 26 Feb 2010 08:40:45 -0500 In-Reply-To: <20100226133149.GA23422@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/2010 03:31 PM, Ingo Molnar wrote: > * Avi Kivity wrote: > > >> 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. >> > You are missing two big things wrt. compatibility here: > > 1) The first upgrade overhead a one time overhead only. > May be one too many, for certain guests. Of course it may be argued that if the guest wants performance monitoring that much, they will upgrade. Certainly guests that we don't port won't be able to use this. I doubt we'll be able to make Windows work with this - the only performance tool I'm familiar with on Windows is Intel's VTune, and that's proprietary. > 2) Once a Linux guest has upgraded, it will work in the future, with _any_ > future CPU - _without_ having to upgrade the guest! > > Dont you see the advantage of that? You can instrument an old system on new > hardware, without having to upgrade that guest for the new CPU support. > That also works for the architectural pmu, of course that's Intel only. And there you don't need to upgrade the guest even once. The arch pmu seems nicely done - there's a bit for every counter that can be enabled and disabled at will, and the number of counters is also determined from cpuid. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.