From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joerg Roedel Subject: Re: KVM PMU virtualization Date: Sun, 28 Feb 2010 17:11:42 +0100 Message-ID: <20100228161142.GA19879@8bytes.org> References: <20100225173423.GB4246@8bytes.org> <20100226084241.GF15885@elte.hu> <4B87987A.2020302@redhat.com> <20100226104437.GB7463@elte.hu> <4B87AF44.9090702@redhat.com> <20100226114217.GI7463@elte.hu> <4B87C354.9020209@redhat.com> <20100226130656.GA2518@elte.hu> <4B87CCF5.6000209@redhat.com> <20100226134400.GB23422@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Avi Kivity , 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 8bytes.org ([88.198.83.132]:48499 "EHLO 8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754373Ab0B1QLo (ORCPT ); Sun, 28 Feb 2010 11:11:44 -0500 Content-Disposition: inline In-Reply-To: <20100226134400.GB23422@elte.hu> Sender: kvm-owner@vger.kernel.org List-ID: On Fri, Feb 26, 2010 at 02:44:00PM +0100, Ingo Molnar wrote: > - A paravirt event driver is more compatible and more transparent in the long > run: it allows hardware upgrade and upgraded PMU functionality (for Linux) > without having to upgrade the guest OS. Via that a guest OS could even be > live-migrated to a different PMU, without noticing anything about it. > > In contrast, a 'stolen', 'raw' PMU directly programmed by the guest OS > always assumes the guest OS is upgraded to the host. Also, 'raw' PMU state > cannot be live-migrated. (save/restore doesnt help) I agree with your arguments, having this soft-pmu for the guest has some advantages over raw pmu access. It has a lot of advantages if the guest migrated between hosts with different hardware. But I still think we should have both, a soft-pmu and a pmu-emulation (which is a more accurate term than 'raw guest pmu access') that looks to the guest as a real hardware pmu would look like. On a linux host that is dedicated to executing virtual kvm machines there is little point in sharing the pmu between guest and host because the host will probably never use it. This pmu-emulation will still use the perf-infrastructure for scheduling the pmu registers, programming the pmu registers and things like that. This could be used for example to emulate 48bit counters for the guest even if the host only supports 32 bit counters. We even need the perf infrastructure when we need to reinject pmu events into the guest. > - It's more secure: the host can have a finegrained policy about what kinds of > events it exposes to the guest. It might chose to only expose software > events for example. What do you mean by software events? Joerg