Received: by 2002:a05:7412:98c1:b0:fa:551:50a7 with SMTP id kc1csp39341rdb; Fri, 5 Jan 2024 01:50:13 -0800 (PST) X-Google-Smtp-Source: AGHT+IFiwc9nMtXw7S6GHFosQqZbpJ0GZ+cd5pR96HcdbfdQcXod3i0pGnNcnTLlU9sZBb7w5K/Y X-Received: by 2002:a25:ce4f:0:b0:db7:dad0:60d6 with SMTP id x76-20020a25ce4f000000b00db7dad060d6mr1513190ybe.99.1704448213297; Fri, 05 Jan 2024 01:50:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704448213; cv=none; d=google.com; s=arc-20160816; b=hJg+PiZ7rj+KFHhs4UDqWgywCUxV4i9rA/UPXDW8QBYkdDmhPWS7W23pMMayj/7fkz U34WmnvqGyomUB6meVv3ptZ9N0Tqs2465zhCTqeIXoHO527Mpxh+I+6sQDlA3uG9nq9U lQyRpRhYyS+j3iR+joOIzF7H6FmuL/4nY9u9ETQn1hb4Rb+wkHk7bxH9CRDzda2SqUm8 tAbEP6d/DJHdnw6bUPdcNmNaHZOIy/8NLNeTQP1Vb3ztY0RxPwtxnsQjclKi7CzPSIZ2 og/0yXKjzmlPJ5xYIQjePQ5gZwrKEoRXmI7mQXZ0mCTVCuWA86Wm4uZDqM3hEdkM9rPd V4Pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=B5mxN9sbrBYXxXcEpKaXdbNPMP0Z4IIank4HDVcYBxk=; fh=mAWlh56xK+Im7SoYEIRk3XCtxN9FRnFpiyQKtltvv94=; b=pnKMngcYueQmHg6VBtU/cwIvYNGbosj4YDAX042ZQ17JRIIVBus4PHLxldaRhtgnb9 qkQTejnAdNthx2y/lZEp2X3f0VcoB6VxVJSMVYfCgIYCaKYw64v4O6mCN8tySDTdYm6V wRGYEI48J1rPRqDUpccIy8lQSdf5wkEa6170jQC1oTpboJIw1XtXCfXQs90RCqpcdPQr UQG+ioKuz6FBb4ONsHTISFR3xtz6hggByL7Z3exRFoic3CnFyaN8D93F0lJ7Rp0Mi9HB +yXzyYL3DzJ2MmTvCeb2rpBlhfUm8lElNfhDY49muwNpDtDa+Mst7dwz6LLPokOw0Dnm WL0A== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-17688-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-17688-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id h8-20020ac85e08000000b00428138cfcffsi1420711qtx.801.2024.01.05.01.50.13 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jan 2024 01:50:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-17688-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-17688-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-17688-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 13E651C22D9B for ; Fri, 5 Jan 2024 09:50:13 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 33A5724A1F; Fri, 5 Jan 2024 09:50:08 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 47F0D249F7 for ; Fri, 5 Jan 2024 09:50:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CFD8BFEC; Fri, 5 Jan 2024 01:50:51 -0800 (PST) Received: from [10.57.44.155] (unknown [10.57.44.155]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id B410B3F5A1; Fri, 5 Jan 2024 01:50:01 -0800 (PST) Message-ID: <8ba4d3dd-6ab2-49e3-9d25-d742e4958afc@arm.com> Date: Fri, 5 Jan 2024 09:50:00 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 6/7] arm64: KVM: Write TRFCR value on guest switch with nVHE Content-Language: en-GB To: James Clark , coresight@lists.linaro.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, broonie@kernel.org, maz@kernel.org, acme@kernel.org Cc: Oliver Upton , James Morse , Zenghui Yu , Catalin Marinas , Will Deacon , Mike Leach , Leo Yan , Alexander Shishkin , Anshuman Khandual , Rob Herring , Miguel Luis , Jintack Lim , Ard Biesheuvel , Mark Rutland , Helge Deller , Arnd Bergmann , Kalesh Singh , Quentin Perret , Vincent Donnefort , Fuad Tabba , Akihiko Odaki , Joey Gouly , Jing Zhang , linux-kernel@vger.kernel.org References: <20240104162714.1062610-1-james.clark@arm.com> <20240104162714.1062610-7-james.clark@arm.com> From: Suzuki K Poulose In-Reply-To: <20240104162714.1062610-7-james.clark@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 04/01/2024 16:27, James Clark wrote: > The guest value for TRFCR requested by the Coresight driver is saved in > kvm_host_global_state. On guest switch this value needs to be written to > the register. Currently TRFCR is only modified when we want to disable > trace completely in guests due to an issue with TRBE. Expand the > __debug_save_trace() function to always write to the register if a > different value for guests is required, but also keep the existing TRBE > disable behavior if that's required. > > The TRFCR restore function remains functionally the same, except a value > of 0 doesn't mean "don't restore" anymore. Now that we save both guest > and host values the register is restored any time the guest and host > values differ. > > Signed-off-by: James Clark > --- > arch/arm64/kvm/hyp/nvhe/debug-sr.c | 55 ++++++++++++++++++------------ > 1 file changed, 34 insertions(+), 21 deletions(-) > > diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c > index 4558c02eb352..7fd876d4f034 100644 > --- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c > +++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c > @@ -51,32 +51,45 @@ static void __debug_restore_spe(u64 pmscr_el1) > write_sysreg_s(pmscr_el1, SYS_PMSCR_EL1); > } > > -static void __debug_save_trace(u64 *trfcr_el1) > +/* > + * Save TRFCR and disable trace completely if TRBE is being used, otherwise > + * apply required guest TRFCR value. > + */ > +static void __debug_save_trace(struct kvm_vcpu *vcpu) > { > - *trfcr_el1 = 0; > + u64 host_trfcr_el1 = read_sysreg_s(SYS_TRFCR_EL1); > + u64 guest_trfcr_el1; > + > + vcpu->arch.host_debug_state.trfcr_el1 = host_trfcr_el1; > > /* Check if the TRBE is enabled */ > - if (!(read_sysreg_s(SYS_TRBLIMITR_EL1) & TRBLIMITR_EL1_E)) > - return; > - /* > - * Prohibit trace generation while we are in guest. > - * Since access to TRFCR_EL1 is trapped, the guest can't > - * modify the filtering set by the host. > - */ > - *trfcr_el1 = read_sysreg_s(SYS_TRFCR_EL1); > - write_sysreg_s(0, SYS_TRFCR_EL1); > - isb(); > - /* Drain the trace buffer to memory */ > - tsb_csync(); > + if (vcpu_get_flag(vcpu, DEBUG_STATE_SAVE_TRBE) && > + (read_sysreg_s(SYS_TRBLIMITR_EL1) & TRBLIMITR_EL1_E)) { > + /* > + * Prohibit trace generation while we are in guest. Since access > + * to TRFCR_EL1 is trapped, the guest can't modify the filtering > + * set by the host. > + */ > + write_sysreg_s(0, SYS_TRFCR_EL1); > + isb(); > + /* Drain the trace buffer to memory */ > + tsb_csync(); > + } else { > + /* > + * Not using TRBE, so guest trace works. Apply the guest filters > + * provided by the Coresight driver, if different. > + */ > + guest_trfcr_el1 = kvm_host_global_state[vcpu->cpu].guest_trfcr_el1; > + if (host_trfcr_el1 != guest_trfcr_el1) > + write_sysreg_s(guest_trfcr_el1, SYS_TRFCR_EL1); > + } > } > > static void __debug_restore_trace(u64 trfcr_el1) > { > - if (!trfcr_el1) > - return; > - > /* Restore trace filter controls */ > - write_sysreg_s(trfcr_el1, SYS_TRFCR_EL1); > + if (trfcr_el1 != read_sysreg_s(SYS_TRFCR_EL1)) > + write_sysreg_s(trfcr_el1, SYS_TRFCR_EL1); Could we not write it unconditionally here ? In the saving step, we have to save the host setting. But while restoring, we could skip the check. A read and write is probably the same cost, as the value is implicitly synchronized by a later ISB. Eitherways, Reviewed-by: Suzuki K Poulose > } > > void __debug_save_host_buffers_nvhe(struct kvm_vcpu *vcpu) > @@ -85,8 +98,8 @@ void __debug_save_host_buffers_nvhe(struct kvm_vcpu *vcpu) > if (vcpu_get_flag(vcpu, DEBUG_STATE_SAVE_SPE)) > __debug_save_spe(&vcpu->arch.host_debug_state.pmscr_el1); > /* Disable and flush Self-Hosted Trace generation */ > - if (vcpu_get_flag(vcpu, DEBUG_STATE_SAVE_TRBE)) > - __debug_save_trace(&vcpu->arch.host_debug_state.trfcr_el1); > + if (vcpu_get_flag(vcpu, DEBUG_STATE_SAVE_TRFCR)) > + __debug_save_trace(vcpu); > } > > void __debug_switch_to_guest(struct kvm_vcpu *vcpu) > @@ -98,7 +111,7 @@ void __debug_restore_host_buffers_nvhe(struct kvm_vcpu *vcpu) > { > if (vcpu_get_flag(vcpu, DEBUG_STATE_SAVE_SPE)) > __debug_restore_spe(vcpu->arch.host_debug_state.pmscr_el1); > - if (vcpu_get_flag(vcpu, DEBUG_STATE_SAVE_TRBE)) > + if (vcpu_get_flag(vcpu, DEBUG_STATE_SAVE_TRFCR)) > __debug_restore_trace(vcpu->arch.host_debug_state.trfcr_el1); > } >