Received: by 2002:a05:7412:98c1:b0:fa:551:50a7 with SMTP id kc1csp45224rdb; Fri, 5 Jan 2024 02:05:47 -0800 (PST) X-Google-Smtp-Source: AGHT+IFciIYz0E0ONPrP8uWeh619fg2L4fyuz1HpNGDCBOn1Lexf/09xSFrOGoiMjWcQK7I13W9T X-Received: by 2002:a17:90a:f2c7:b0:28c:1eff:ac45 with SMTP id gt7-20020a17090af2c700b0028c1effac45mr1646786pjb.77.1704449147126; Fri, 05 Jan 2024 02:05:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704449147; cv=none; d=google.com; s=arc-20160816; b=tE9hlMAZ46zLLMIoo9ikVf28RwhorMN7yxzWmKxb3L3dXURSGrbimWAPuGAZ2ZCViM rQclY6p7elshNE3NfPyaMIWrABUh130yzH0fBf5o8cKcqTxIC4Mst8kJqmFZBJeN3pPs KMhi56+5djQ09fuRUea1cjnopeb77vRUG9NYuur9CdPcZAUkQroMEd4eMO8H8iUI49zQ MOB4UjkUC/mqXTYZq6MGmJ2kZ08UUe/mMvcvOWkbPvJ51TKL3shRjwrZgFQZuGkcIjaA AdeuNzXI+byJgC7Zr1WQFfCohxsZVeUne9bFOQjj/oG+YAJSEMUjoAOrRe0jyH4jKqZI eFRA== 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=3M3QD06o0Oe6K8KHLxy59KL7Mq2dzWfneePENrAwzo0=; fh=G2QJm+Yz6o/uyRJVtGFnVNYttwov/0NfQ2GpvKZI96I=; b=QlTdxeadAltO5zyB89lC5IszInLK4RQH+bJCKrTUrIEGStbZBYWLuttVjzC2Am7fjK T/tCks26luQrZin60LjRYgcnKiYropFN5Rz1sqvaaMIoyD8RRqCg516MsRnQW9fI4h9V 5Iaf0EU0KytuteDwgQWIC73YCOJEw8p0mL4Bfx+ysh23jNn/y9Fks4rSh0ZjQu3Rttrm MpWCKWy1AkEKiLVAIvdicXP3XPQPOULghLV7C8U331e1I+rySQwGU7YL+HbTMnWtnYsn INYjlPKuXngrdZkk5toK9TgLfnqvK9wEeDZXz5BLmZ5w3O6rBwddKQnDyw0lStPJjGgA wdoA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-17709-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-17709-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id q16-20020a17090311d000b001d348572011si1001802plh.231.2024.01.05.02.05.46 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 05 Jan 2024 02:05:47 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-17709-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-17709-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-17709-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 sy.mirrors.kernel.org (Postfix) with ESMTPS id BD441B22C71 for ; Fri, 5 Jan 2024 10:05:32 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id DC530250E7; Fri, 5 Jan 2024 10:05:12 +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 8BA6B24B59 for ; Fri, 5 Jan 2024 10:05:10 +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 2BAA8FEC; Fri, 5 Jan 2024 02:05:56 -0800 (PST) Received: from [192.168.32.22] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 1DF423F64C; Fri, 5 Jan 2024 02:05:02 -0800 (PST) Message-ID: Date: Fri, 5 Jan 2024 10:05:08 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 Subject: Re: [PATCH v4 6/7] arm64: KVM: Write TRFCR value on guest switch with nVHE Content-Language: en-US To: Suzuki K Poulose , 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> <8ba4d3dd-6ab2-49e3-9d25-d742e4958afc@arm.com> From: James Clark In-Reply-To: <8ba4d3dd-6ab2-49e3-9d25-d742e4958afc@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05/01/2024 09:50, Suzuki K Poulose wrote: > 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 > > I did also wonder if it was better to just do it unconditionally. I'll update it in the next version. >>   } >>     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); >>   } >>   >