From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH v1 0/5] KVM in-guest performance monitoring Date: Thu, 12 May 2011 15:23:39 +0200 Message-ID: <4DCBDF5B.6000101@siemens.com> References: <1305129333-7456-1-git-send-email-avi@redhat.com> <20110512093309.GD8707@8bytes.org> <4DCBACC7.8080000@siemens.com> <20110512131130.GG8707@8bytes.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Avi Kivity , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , Ingo Molnar , Peter Zijlstra , Arnaldo Carvalho de Melo To: Joerg Roedel Return-path: In-Reply-To: <20110512131130.GG8707@8bytes.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 2011-05-12 15:11, Joerg Roedel wrote: > On Thu, May 12, 2011 at 11:47:51AM +0200, Jan Kiszka wrote: >> On 2011-05-12 11:33, Joerg Roedel wrote: > >>> Anyway, I thought about a paravirt-approach instead of implementing a >>> real PMU... But there are certainly good reasons for both. >> >> Paravirt is taking away the pressure from CPU vendors to do their virt >> extensions properly - and doesn't help with unmodifiable OSes. > > Seriously, I think such decisions should be technical only and not > political like that. The losers of such political decisions are always > the users because they don't get useful features that are technical > possible. Paravirt remains a workaround, useful until hardware provides a solution for all guests, and that often in an even more efficient way (like for MMU virtualization). We do not need to block a PV-PMU for Linux guests (or other OSes that want to adopt to it), but that will not be a solution for the problem, that's my point. A PV-PMU may even be useful to demonstrate usefulness of a virtual PMU the CPU vendors (if they aren't aware of this yet). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux