From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM PMU virtualization Date: Fri, 26 Feb 2010 15:44:51 +0200 Message-ID: <4B87D053.5080700@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> <1267190907.22519.601.camel@laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Ingo Molnar , Jes Sorensen , Joerg Roedel , KVM General , Zachary Amsden , Gleb Natapov , ming.m.lin@intel.com, "Zhang, Yanmin" , Thomas Gleixner , "H. Peter Anvin" , Arjan van de Ven , Fr??d??ric Weisbecker , Arnaldo Carvalho de Melo To: Peter Zijlstra Return-path: Received: from mx1.redhat.com ([209.132.183.28]:13673 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936270Ab0BZNpb (ORCPT ); Fri, 26 Feb 2010 08:45:31 -0500 In-Reply-To: <1267190907.22519.601.camel@laptop> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/2010 03:28 PM, Peter Zijlstra wrote: > On Fri, 2010-02-26 at 13:51 +0200, Avi Kivity wrote: > > >> It would be the other way round - the host would steal the pmu from the >> guest. Later we can try to time-slice and extrapolate, though that's >> not going to be easy. >> > Right, so perf already does the time slicing and interpolating thing, so > a soft-pmu gets that for free. > True. > Anyway, this discussion seems somewhat in a stale-mate position. > > The KVM folks basically demand a full PMU MSR shadow with PMI > passthrough so that their $legacy shit works without modification. > > My question with that is how $legacy muck can ever know how the current > PMU works, you can't even properly emulate a core2 pmu on a nehalem > because intel keeps messing with the event codes for every new model. > Right, this is pretty bad. For Windows it's probably acceptable to upgrade your performance tools (since that's separate from the OS). In Linux it is integrated into the kernel, and it's fairly unacceptable to demand a kernel upgrade when your host is upgraded underneath you. > So basically for this to work means the guest can't run legacy stuff > anyway, but needs to run very up-to-date software, so we might as well > create a soft-pmu/paravirt interface now and have all up-to-date > software support that for the next generation. > Still that leaves us with no Windows / non-Linux solution. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.