From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: KVM PMU virtualization Date: Mon, 01 Mar 2010 08:54:48 -1000 Message-ID: <4B8C0D78.8000600@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> <4B87CE93.1070906@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ingo Molnar , Avi Kivity , Joerg Roedel , KVM General , Peter Zijlstra , 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: Jes Sorensen Return-path: Received: from mx1.redhat.com ([209.132.183.28]:1959 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750947Ab0CASzd (ORCPT ); Mon, 1 Mar 2010 13:55:33 -0500 In-Reply-To: <4B87CE93.1070906@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/2010 03:37 AM, Jes Sorensen wrote: > On 02/26/10 14:31, Ingo Molnar wrote: >> You are missing two big things wrt. compatibility here: >> >> 1) The first upgrade overhead a one time overhead only. >> >> 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 would only work if you are guaranteed to be able to emulate old > hardware on new hardware. Not going to be feasible, so then we are in a > real mess. > >> With the 'steal the PMU' messy approach the guest OS has to be >> upgraded to the >> new CPU type all the time. Ad infinitum. > > The way the Perfmon architecture is specified by Intel, that is what we > are stuck with. It's not going to be possible via software emulation to > count cache misses, unless you run it in a micro architecture emulator. Sure you can count cache misses. Step 1. Declare KVM to possess a virtual cache hereto unseen to guest VCPUs. Step 2. Use micro architecture rules to add to cache misses in an undefined micro-architecture specific way Step 3. Step 4. PROFIT! The point being, there are no rules required to follow for architecturally unspecified events. Instructions issued is well defined architecturally, one of very few such counters, while things like cache strides and organization are deliberately left to the implementation. So returning zero is a perfectly valid choice for emulating cache misses. Zach