From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jes Sorensen Subject: Re: KVM PMU virtualization Date: Fri, 26 Feb 2010 15:07:25 +0100 Message-ID: <4B87D59D.5050402@redhat.com> References: <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> <20100226123850.GA19476@elte.hu> <4B87C6C4.3040407@redhat.com> <4B87C8EC.8080304@redhat.com> <20100226132751.GA20013@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]:26759 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964810Ab0BZOIT (ORCPT ); Fri, 26 Feb 2010 09:08:19 -0500 In-Reply-To: <20100226132751.GA20013@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/10 14:27, Ingo Molnar wrote: > > * Jes Sorensen wrote: >> You certainly cannot emulate the Core2 on a P4. The Core2 is Perfmon v2, >> whereas Nehalem and Atom are v3 if I remember correctly. [...] > > Of course you can emulate a good portion of it, as long as there's perf > support on the host side for P4. Actually P4 is pretty uninteresting in this discussion due to the lack of VMX support, it's the same issue for Nehalem vs Core2. The problem is the same though, we cannot tell the guest that yes P4 has this event, but no, we are going to feed you bogus data. > If the guest programs a cachemiss event, you program a cachemiss perf event on > the host and feed its values to the emulated MSR state. You _dont_ program the > raw PMU on the host side - just use the API i outlined to get struct > perf_event. > > The emulation wont be perfect: not all events will count and not all events > will be available in a P4 (and some Core2 events might not even make sense in > a P4), but that is reality as well: often documented events dont count, and > often non-documented events count. > > What matters to 99.9% of people who actually use this stuff is a few core sets > of events - which are available in P4s and in Core2 as well. Cycles, > instructions, branches, maybe cache-misses. Sometimes FPU stuff. I really do not like to make guesses about how people use this stuff. The things you and I look for as kernel hackers are often very different than application authors look for and use. That is one thing I learned from being expose to strange Fortran programmers at SGI. It makes me very uncomfortable telling a guest OS that we offer features X, Y, Z and then start lying feeding back numbers that do not match what was requested, and there is no way to to tell the guest that. > For Linux<->Linux the sanest, tier-1 approach would be to map sys_perf_open() > on the guest side over to the host, transparently, via a paravirt driver. Paravirt is a nice optimization, but is and will always be an optimization. Fact of the matter is that the bulk of usage of virtualization is for running distributions with slow kernel upgrade rates, like SLES and RHEL, and other proprietary operating systems which we have no control over. Para-virt will do little good for either of these groups. Cheers, Jes