Received: by 2002:a05:7412:d1aa:b0:fc:a2b0:25d7 with SMTP id ba42csp778999rdb; Mon, 29 Jan 2024 19:41:51 -0800 (PST) X-Google-Smtp-Source: AGHT+IHPco+OnOMZ/8fowGVGUX8zcMdmnk3eqpRUKwjNKAyuN9guE/DJN+tkixomMnr+NpbAgu3o X-Received: by 2002:aa7:cfcb:0:b0:55f:30dc:a72f with SMTP id r11-20020aa7cfcb000000b0055f30dca72fmr996418edy.7.1706586111234; Mon, 29 Jan 2024 19:41:51 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706586111; cv=pass; d=google.com; s=arc-20160816; b=pGVsS8/IyAjC/5R8Eadn3fnesjvcWSeFhS2FnXbhdYQOqnDG1dluURjnDC8J5lSMm7 DIYNzfQ4qmb8WElPmf20JiIt2kNu9InvSUZJgkUehbh0tCia68r25gyM0EuNJgM/Z65g NTVHNniwHHlqeeAhDRXzxk9pYuKrfOdaM9g6GCPUnW0TqZqwpKfoKCtEl/RtrenvSEcV NcFc6h32yfpJLQu6JiCn0WRTxVwabc+HGbOCh2PV8/8W8YHzkBh33bSKtY5BSR25tJ6I 6e5p+oQcw+QKBjMDQSNiLa1iRqWy7NGWEEtGVvg5Nk7J2N1mlzzUanDTsbILl4R2M/2O HMtA== ARC-Message-Signature: i=2; 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=VzeQLApWWL6zrQ3tts3nUEmxM/XxqTwbxahZOgT+FQ4=; fh=81zzucHMR1zPhyjNRse4vzHA5m/aoVXeDl/kgiMEPQA=; b=BPpWmRfD6Mk13iW2JgCs8GfPt+MPJxfUAVh7SC/CmTKGBepFCR/+PdGnaJV8e0ux3M e4K8PW2DWgOaOqh8l8PFS8Cj0sVOjXWhKvU3vpxV6AGa8qDPvqNYE5NPZmQlzkFI3kVd Y7rX/jbHWmJePAQZYJA7I75aEMaskuO9lpY5eGi/WcVGXBmDIEDdCxEzLyxs5WePkePw wQkfO32mFP88d2UdXgQH3ylXxR6ZvZXiZPHJ9k9kyQhcWoCgJfBkmXECGaN00NEPkDf1 mzHz6rr4oOxdBhtFVz9Mhhlo0pd3DNfvULwOj/LWFhmXj8J58I9aoSyZe4ZoOkwg4wU7 rauA== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-43911-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-43911-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id em7-20020a056402364700b0055eb6f3bb4asi3047146edb.445.2024.01.29.19.41.51 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jan 2024 19:41:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-43911-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-43911-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-43911-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 am.mirrors.kernel.org (Postfix) with ESMTPS id CEB721F2463A for ; Tue, 30 Jan 2024 03:41:50 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 5B676376EC; Tue, 30 Jan 2024 03:41:40 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6FE3E36133; Tue, 30 Jan 2024 03:41:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706586099; cv=none; b=UAbNEBFNfYhKDoGnzOjot7ko270jdbp/m2nN0xkGrkMHUteQdancJ8UxpnN6u+ht+HWgQhmx/6H5hz8Ba0WRLEt+7FGGALkUu9BRmdxST0/W8TARn4UX5QQSciVWNHXRtKG6r7WFZg8dAV6OFuAbMVrD64R+V7gVi3dbf8gn7bc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706586099; c=relaxed/simple; bh=MS9XkrHIxAOgVMwkPgUdkJNkZsvXrigVFaMPH+MQ3tg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=G4c7qY+2+qfpPolS4Vur3iUf+g3Wkzf49raIc7dAmDNOWmPbzD4TPOXyK5d8pk1L9hrwXsZRKraVvAfN5pBqn+m8JVndXSrsMLCKkeIy5xhnnGg8wJf/bVZ76ZUqaXNsZT1aLE2RJJanpsjvCy62C/0Lg4sx9lZXMJJ5lXM72ZI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 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 B6419DA7; Mon, 29 Jan 2024 19:42:20 -0800 (PST) Received: from [10.163.41.110] (unknown [10.163.41.110]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CE7BE3F738; Mon, 29 Jan 2024 19:41:30 -0800 (PST) Message-ID: Date: Tue, 30 Jan 2024 09:11:30 +0530 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 V16 5/8] KVM: arm64: nvhe: Disable branch generation in nVHE guests Content-Language: en-US To: Suzuki K Poulose , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, will@kernel.org, catalin.marinas@arm.com, mark.rutland@arm.com Cc: Mark Brown , James Clark , Rob Herring , Marc Zyngier , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , linux-perf-users@vger.kernel.org, Oliver Upton , James Morse , kvmarm@lists.linux.dev References: <20240125094119.2542332-1-anshuman.khandual@arm.com> <20240125094119.2542332-6-anshuman.khandual@arm.com> From: Anshuman Khandual In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 1/29/24 17:50, Suzuki K Poulose wrote: > On 25/01/2024 09:41, Anshuman Khandual wrote: >> Disable the BRBE before we enter the guest, saving the status and enable it >> back once we get out of the guest. This avoids capturing branch records in >> the guest kernel or userspace, which would be confusing the host samples. >> >> Cc: Marc Zyngier >> Cc: Oliver Upton >> Cc: James Morse >> Cc: Suzuki K Poulose >> Cc: Catalin Marinas >> Cc: Will Deacon >> Cc: kvmarm@lists.linux.dev >> Cc: linux-arm-kernel@lists.infradead.org >> CC: linux-kernel@vger.kernel.org >> Signed-off-by: Anshuman Khandual >> --- >> Changes in V16: >> >> - Dropped BRBCR_EL1 and BRBFCR_EL1 from enum vcpu_sysreg >> - Reverted back the KVM NVHE patch - used host_debug_state based 'brbcr_el1' >>    element, and dropped the previous dependency on Jame's coresight series >> >>   arch/arm64/include/asm/kvm_host.h  |  5 ++++- >>   arch/arm64/kvm/debug.c             |  5 +++++ >>   arch/arm64/kvm/hyp/nvhe/debug-sr.c | 33 ++++++++++++++++++++++++++++++ >>   3 files changed, 42 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h >> index 21c57b812569..bce8792092af 100644 >> --- a/arch/arm64/include/asm/kvm_host.h >> +++ b/arch/arm64/include/asm/kvm_host.h >> @@ -569,7 +569,7 @@ struct kvm_vcpu_arch { >>       u8 cflags; >>         /* Input flags to the hypervisor code, potentially cleared after use */ >> -    u8 iflags; >> +    u16 iflags; >>         /* State flags for kernel bookkeeping, unused by the hypervisor code */ >>       u8 sflags; >> @@ -610,6 +610,7 @@ struct kvm_vcpu_arch { >>           u64 pmscr_el1; >>           /* Self-hosted trace */ >>           u64 trfcr_el1; >> +        u64 brbcr_el1; >>       } host_debug_state; >>         /* VGIC state */ >> @@ -779,6 +780,8 @@ struct kvm_vcpu_arch { >>   #define DEBUG_STATE_SAVE_TRBE    __vcpu_single_flag(iflags, BIT(6)) >>   /* vcpu running in HYP context */ >>   #define VCPU_HYP_CONTEXT    __vcpu_single_flag(iflags, BIT(7)) >> +/* Save BRBE context if active  */ >> +#define DEBUG_STATE_SAVE_BRBE    __vcpu_single_flag(iflags, BIT(8)) >>     /* SVE enabled for host EL0 */ >>   #define HOST_SVE_ENABLED    __vcpu_single_flag(sflags, BIT(0)) >> diff --git a/arch/arm64/kvm/debug.c b/arch/arm64/kvm/debug.c >> index 8725291cb00a..99f85d8acbf3 100644 >> --- a/arch/arm64/kvm/debug.c >> +++ b/arch/arm64/kvm/debug.c >> @@ -335,10 +335,15 @@ void kvm_arch_vcpu_load_debug_state_flags(struct kvm_vcpu *vcpu) >>       if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_TraceBuffer_SHIFT) && >>           !(read_sysreg_s(SYS_TRBIDR_EL1) & TRBIDR_EL1_P)) >>           vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_TRBE); >> + >> +    /* Check if we have BRBE implemented and available at the host */ >> +    if (cpuid_feature_extract_unsigned_field(dfr0, ID_AA64DFR0_EL1_BRBE_SHIFT)) >> +        vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_BRBE); >>   } >>     void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu) >>   { >>       vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_SPE); >>       vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_TRBE); >> +    vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_BRBE); >>   } >> diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c >> index 4558c02eb352..79bcf0fb1326 100644 >> --- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c >> +++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c >> @@ -79,6 +79,34 @@ static void __debug_restore_trace(u64 trfcr_el1) >>       write_sysreg_s(trfcr_el1, SYS_TRFCR_EL1); >>   } >>   +static void __debug_save_brbe(u64 *brbcr_el1) >> +{ >> +    *brbcr_el1 = 0; >> + >> +    /* Check if the BRBE is enabled */ >> +    if (!(read_sysreg_s(SYS_BRBCR_EL1) & (BRBCR_ELx_E0BRE | BRBCR_ELx_ExBRE))) >> +        return; >> + >> +    /* >> +     * Prohibit branch record generation while we are in guest. >> +     * Since access to BRBCR_EL1 is trapped, the guest can't >> +     * modify the filtering set by the host. >> +     */ >> +    *brbcr_el1 = read_sysreg_s(SYS_BRBCR_EL1); >> +    write_sysreg_s(0, SYS_BRBCR_EL1); >> +    isb(); > > Is this isb() required here ? This can be synchronised with the Guest entry ? > >> +} >> + >> +static void __debug_restore_brbe(u64 brbcr_el1) >> +{ >> +    if (!brbcr_el1) >> +        return; >> + >> +    /* Restore BRBE controls */ >> +    write_sysreg_s(brbcr_el1, SYS_BRBCR_EL1); >> +    isb(); > > Similarly here, exit back to EL1 host can synchronise the setting ? Sure, will drop both the isb() here.