From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM PMU virtualization Date: Fri, 26 Feb 2010 12:51:29 +0200 Message-ID: <4B87A7B1.9000606@redhat.com> References: <4B86917C.4070102@redhat.com> <20100225173423.GB4246@8bytes.org> <20100226084241.GF15885@elte.hu> <4B87987A.2020302@redhat.com> <20100226103934.GD4246@8bytes.org> <20100226104659.GC7463@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Joerg Roedel , Jes Sorensen , 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]:20851 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933370Ab0BZKwI (ORCPT ); Fri, 26 Feb 2010 05:52:08 -0500 In-Reply-To: <20100226104659.GC7463@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/2010 12:46 PM, Ingo Molnar wrote: > >>> Right, this will severely limit migration domains to hosts of the same >>> vendor and processor generation. There is a middle ground, though, >>> Intel has recently moved to define an "architectural pmu" which is not >>> model specific. I don't know if AMD adopted it. We could offer both >>> options - native host capabilities, with a loss of compatibility, and >>> the architectural pmu, with loss of model specific counters. >>> >> I only had a quick look yet on the architectural pmu from intel but it looks >> like it can be emulated for a guest on amd using existing features. >> > AMD CPUs dont have enough events for that, they cannot do the 3 fixed events > in addition to the 2 generic ones. > > Nor do you really want to standardize on KVM guests on returning > 'GenuineIntel' in CPUID, so that the various guest side OSs use the Intel PMU > drivers, right? > > No - that would only work if AMD also adopted the architectural pmu. Note virtualization clusters are typically split into 'migration pools' consisting of hosts with similar processor features, so that you can expose those features and yet live migrate guests at will. It's likely that all hosts have the same pmu anyway, so the only downside is that we now have to expose the host's processor family and model. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.