From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM PMU virtualization Date: Fri, 26 Feb 2010 18:03:05 +0200 Message-ID: <4B87F0B9.50707@redhat.com> References: <20100226104437.GB7463@elte.hu> <4B87AF44.9090702@redhat.com> <20100226114217.GI7463@elte.hu> <4B87B5DE.30503@redhat.com> <20100226120750.GA11578@elte.hu> <4B87BC74.7050207@redhat.com> <20100226133149.GA23422@elte.hu> <4B87CF39.4080801@redhat.com> <20100226140105.GC23422@elte.hu> <4B87D927.6010401@redhat.com> <20100226143724.GF23422@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]:38291 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965060Ab0BZQDi (ORCPT ); Fri, 26 Feb 2010 11:03:38 -0500 In-Reply-To: <20100226143724.GF23422@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On 02/26/2010 04:37 PM, Ingo Molnar wrote: > * Avi Kivity wrote: > > >>>> Certainly guests that we don't port won't be able to use this. I doubt >>>> we'll be able to make Windows work with this - the only performance tool I'm >>>> familiar with on Windows is Intel's VTune, and that's proprietary. >>>> >>> Dont you see the extreme irony of your wish to limit Linux kernel design >>> decisions and features based on ... Windows and other proprietary >>> software? >>> >> Not at all. Virtualization is a hardware compatibility game. To see what >> happens if you don't play it, see Xen. Eventually they to implemented >> hardware support even though the pv approach is so wonderful. >> > That's not quite equivalent though. > > KVM used to be the clean, integrate-code-with-Linux virtualization approach, > designed specifically for CPUs that can be virtualized properly. (VMX support > first, then SVM, etc.) > > KVM virtualized ages-old concepts with relatively straightforward hardware > ABIs: x86 execution, IRQ abstractions, device abstractions, etc. > > Now you are in essence turning that all around: > > - the PMU is by no means properly virtualized nor really virtualizable by > direct access. There's no virtual PMU that ticks independently of the host > PMU. > There's no guest debug registers that can be programmed independently of the host debug registers, but we manage somehow. It's not perfect, but better than nothing. For the common case of host-only or guest-only monitoring, things will work, perhaps without socketwide counters in security concious environments. When both are used at the same time, something will have to give. > - the PMU hardware itself is not a well standardized piece of hardware. It's > very vendor dependent and very limiting. > That's life. If we force standardization by having a soft pmu, we'll be very limited as well. If we don't, we reduce hardware independence which is a strong point of virtualization. Clearly we need to make a trade-off here. In favour of hardware dependence is that tools and users are already used to it. There is also the architectural pmu that can provide a limited form of hardware independence. Going pv trades off hardware dependence for software dependence. Suddenly only guests that you have control over can use the pmu. > So to some degree you are playing the role of Xen in this specific affair. You > are pushing for something that shouldnt be done in that form. You want to > interfere with the host PMU by going via the fast& easy short-term hack to > just let the guest OS have the PMU, without any regard to how this impacts > long-term feasible solutions. > Maybe. And maybe the vendors will improve virtualization support for the pmu, rendering the pv approach obsolete on new hardware. > I.e. you are a bit like the guy who would have told Linus in 1994: > > " Dude, why dont you use the Windows APIs? It's far more compatible and > that's the only way you could run any serious apps. Besides, it requires > no upgrade. Admittedly it's a bit messy and 16-bit but hey, that's our > installed base after all. " > Hey, maybe we'd have significant desktop market share if he'd done this (though a replay of the wine history is much more likely). But what are you suggesting? That we make Windows a second class guest? Most users run a mix of workloads, that will not go down well with them. The choice is between first-class Windows support vs becoming a hobby hypervisor. Let's make a kerner/user analogy again. Would you be in favour of GPL-only-ing new syscalls, to give open source applications an edge over proprietary apps (technically known as "crap" among some)? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.