From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM PMU virtualization Date: Fri, 26 Feb 2010 11:46:34 +0200 Message-ID: <4B87987A.2020302@redhat.com> References: <4B86917C.4070102@redhat.com> <20100225173423.GB4246@8bytes.org> <20100226084241.GF15885@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]:33216 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935773Ab0BZJr1 (ORCPT ); Fri, 26 Feb 2010 04:47:27 -0500 In-Reply-To: <20100226084241.GF15885@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/2010 10:42 AM, Ingo Molnar wrote: > * Joerg Roedel wrote: > > >> I personally don't like a self-defined event-set as the only solution >> because that would probably only work with linux and perf. [...] >> > The 'soft-PMU' i suggested is transparent on the guest side - if you want to > enable non-Linux and legacy-Linux. > > It's basically a PMU interface provided to the guest by catching the right MSR > accesses, implemented via perf_event_create_kernel_counter()/etc. on the host > side. > That only works if the software interface is 100% lossless - we can recreate every single hardware configuration through the API. Is this the case? > Note that the 'soft PMU' still sucks from a design POV as there's no generic > hw interface to the PMU. So there would have to be a 'soft AMD' and a 'soft > Intel' PMU driver at minimum. > 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. > Far cleaner would be to expose it via hypercalls to guest OSs that are > interested in instrumentation. It's also slower - you can give the guest direct access to the various counters so no exits are taken when reading the counters (though perhaps many tools are only interested in the interrupts, not the counter values). > That way it could also transparently integrate > with tracing, probes, etc. It would also be wiser to first concentrate on > improving Linux<->Linux guest/host combos before gutting the design just to > fit Windows into the picture ... > "gutting the design"? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.