From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4B742C2D0C0 for ; Sun, 22 Dec 2019 10:44:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 15CD3206D3 for ; Sun, 22 Dec 2019 10:44:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1577011442; bh=BBS3PE0B8EDqa6rPdChky2RlLv/xtZf4Llda1PV8bPM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:List-ID:From; b=qyD2hvJxQkMROMj3Iht764ktSZ+3uJlhLPrziOXj8H34EheN0ZIxNBgraABLMus9R tBfI/Z92+3qs9xKJQJtGBMkNKQwt7divA6Ab1z/6oq6QWK6ToozMUdG6515eUCpLbe 29tPKNAkban7xB/sWcLXlYY/PZCefjbzqb7xh1WY= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726671AbfLVKn7 (ORCPT ); Sun, 22 Dec 2019 05:43:59 -0500 Received: from inca-roads.misterjones.org ([213.251.177.50]:51308 "EHLO inca-roads.misterjones.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725977AbfLVKn7 (ORCPT ); Sun, 22 Dec 2019 05:43:59 -0500 Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=big-swifty.misterjones.org) by cheepnis.misterjones.org with esmtpsa (TLSv1.2:AES256-GCM-SHA384:256) (Exim 4.80) (envelope-from ) id 1iiygN-0005Y6-Rv; Sun, 22 Dec 2019 11:43:56 +0100 Date: Sun, 22 Dec 2019 10:42:05 +0000 Message-ID: <86bls0iqv6.wl-maz@kernel.org> From: Marc Zyngier To: Andrew Murray Cc: Marc Zyngier , Catalin Marinas , Will Deacon , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Sudeep Holla , kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 11/18] KVM: arm64: don't trap Statistical Profiling controls to EL2 In-Reply-To: <20191220143025.33853-12-andrew.murray@arm.com> References: <20191220143025.33853-1-andrew.murray@arm.com> <20191220143025.33853-12-andrew.murray@arm.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 EasyPG/1.0.0 Emacs/26 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: andrew.murray@arm.com, marc.zyngier@arm.com, catalin.marinas@arm.com, will.deacon@arm.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, sudeep.holla@arm.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on cheepnis.misterjones.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 20 Dec 2019 14:30:18 +0000, Andrew Murray wrote: > > As we now save/restore the profiler state there is no need to trap > accesses to the statistical profiling controls. Let's unset the > _TPMS bit. > > Signed-off-by: Andrew Murray > --- > arch/arm64/kvm/debug.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c > index 43487f035385..07ca783e7d9e 100644 > --- a/arch/arm64/kvm/debug.c > +++ b/arch/arm64/kvm/debug.c > @@ -88,7 +88,6 @@ void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu) > * - Performance monitors (MDCR_EL2_TPM/MDCR_EL2_TPMCR) > * - Debug ROM Address (MDCR_EL2_TDRA) > * - OS related registers (MDCR_EL2_TDOSA) > - * - Statistical profiler (MDCR_EL2_TPMS/MDCR_EL2_E2PB) > * > * Additionally, KVM only traps guest accesses to the debug registers if > * the guest is not actively using them (see the KVM_ARM64_DEBUG_DIRTY > @@ -111,7 +110,6 @@ void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) > */ > vcpu->arch.mdcr_el2 = __this_cpu_read(mdcr_el2) & MDCR_EL2_HPMN_MASK; > vcpu->arch.mdcr_el2 |= (MDCR_EL2_TPM | > - MDCR_EL2_TPMS | No. This is an *optional* feature (the guest could not be presented with the SPE feature, or the the support simply not be compiled in). If the guest is not allowed to see the feature, for whichever reason, the traps *must* be enabled and handled. M. -- Jazz is not dead, it just smells funny.