From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM PMU virtualization Date: Fri, 26 Feb 2010 13:16:25 +0200 Message-ID: <4B87AD89.60209@redhat.com> References: <4B86917C.4070102@redhat.com> <20100225173423.GB4246@8bytes.org> <20100226084241.GF15885@elte.hu> <4B87987A.2020302@redhat.com> <20100226104437.GB7463@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]:35057 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934166Ab0BZLRP (ORCPT ); Fri, 26 Feb 2010 06:17:15 -0500 In-Reply-To: <20100226104437.GB7463@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/2010 12:44 PM, Ingo Molnar wrote: >>> 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). >> > Direct access to counters is not something that is a big issue. [ Given that i > sometimes can see KVM redraw the screen of a guest OS real-time i doubt this > is the biggest of performance challenges right now ;-) ] > Outside 4-bit vga mode, this shouldn't happen. Can you describe your scenario? > By far the biggest instrumentation issue is: > > - availability > - usability > - flexibility > > Exposing the raw hw is a step backwards in many regards. In a way, virtualization as a whole is a step backwards. We take the nice firesystem/timer/network/scheduler APIs, and expose them as raw hardware. The pmu isn't any different. > The same way we dont > want to expose chipsets to the guest to allow them to do RAS. The same way we > dont want to expose most raw PCI devices to guest in general, but have all > these virt driver abstractions. > Whenever we have a choice, we expose raw hardware (usually emulated, but in some cases real). Raw hardware has the huge advantage of being already supported. Write a software abstraction, and you get to (a) write and maintain the spec (b) write drivers for all guests (c) mumble something to users of OSes to which you haven't ported your driver (d) explain to users that they need to install those drivers. For networking and block, it is simply impossible to obtain good performance without introducing a new interface, but for other stuff, that may not be the case. >>> 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"? >> > Yes, gutting the design of a sane instrumentation API and moving it back 10-20 > years by squeezing it through non-standardized and incompatible PMU drivers. > Any new interface will be incompatible to all the exiting guests out there; and unlike networking, you can't retrofit a pmu interface to an existing guest. > When it comes to design my main interest is the Linux<->Linux combo. > My main interest is the OSes that users actually install, and those are Windows and non-bleeding-edge Linux. Look at guests as you do at userspace: you don't want to inflict changes upon them. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.