From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM PMU virtualization Date: Fri, 26 Feb 2010 14:20:04 +0200 Message-ID: <4B87BC74.7050207@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> 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]:9742 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935899Ab0BZMXu (ORCPT ); Fri, 26 Feb 2010 07:23:50 -0500 In-Reply-To: <20100226120750.GA11578@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/2010 02:07 PM, Ingo Molnar wrote: > * Avi Kivity wrote: > > >> A native API to the host will lock out 100% of the install base now, and a >> large section of any future install base. >> > ... which is why i suggested the soft-PMU approach. > Not sure I understand it completely. Do you mean to take the model specific host pmu events, and expose them to the guest via trap'n'emulate? In that case we may as well assign the host pmu to the guest if the host isn't using it, and avoid the traps. Do you mean to choose some older pmu and emulate it using whatever pmu model the host has? I haven't checked, but aren't there mutually exclusive events in every model pair? The closest thing would be the architectural pmu thing. 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. > And note that _any_ solution we offer locks out 100% of the installed base > right now, as no solution is in the kernel yet. The only question is what kind > of upgrade effort is needed for users to make use of the feature. > I meant the guest installed base. Hosts can be upgraded transparently to the guests (not even a shutdown/reboot). -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.