Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756832Ab1ELNYH (ORCPT ); Thu, 12 May 2011 09:24:07 -0400 Received: from goliath.siemens.de ([192.35.17.28]:21905 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752910Ab1ELNYF (ORCPT ); Thu, 12 May 2011 09:24:05 -0400 Message-ID: <4DCBDF5B.6000101@siemens.com> Date: Thu, 12 May 2011 15:23:39 +0200 From: Jan Kiszka User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Joerg Roedel CC: Avi Kivity , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" , Ingo Molnar , Peter Zijlstra , Arnaldo Carvalho de Melo Subject: Re: [PATCH v1 0/5] KVM in-guest performance monitoring References: <1305129333-7456-1-git-send-email-avi@redhat.com> <20110512093309.GD8707@8bytes.org> <4DCBACC7.8080000@siemens.com> <20110512131130.GG8707@8bytes.org> In-Reply-To: <20110512131130.GG8707@8bytes.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1450 Lines: 34 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/