From: Anshuman Khandual <anshuman.khandual@arm.com>
To: James Clark <james.clark@arm.com>
Cc: Mark Brown <broonie@kernel.org>, Rob Herring <robh@kernel.org>,
Marc Zyngier <maz@kernel.org>,
Suzuki Poulose <suzuki.poulose@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
linux-perf-users@vger.kernel.org,
Oliver Upton <oliver.upton@linux.dev>,
James Morse <james.morse@arm.com>,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, will@kernel.org,
catalin.marinas@arm.com, mark.rutland@arm.com
Subject: Re: [V14 5/8] KVM: arm64: nvhe: Disable branch generation in nVHE guests
Date: Tue, 21 Nov 2023 16:42:18 +0530 [thread overview]
Message-ID: <20858eb9-a4d0-41be-ad1d-2a5f2d2fa0de@arm.com> (raw)
In-Reply-To: <f2661879-636c-1865-0e1c-60d8e11f80f0@arm.com>
On 11/14/23 14:46, James Clark wrote:
>
>
> On 14/11/2023 05:13, 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 is just to avoid capturing records
>> in the guest kernel/userspace, which would be confusing the samples.
>>
>> Cc: Marc Zyngier <maz@kernel.org>
>> Cc: Oliver Upton <oliver.upton@linux.dev>
>> Cc: James Morse <james.morse@arm.com>
>> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: kvmarm@lists.linux.dev
>> Cc: linux-arm-kernel@lists.infradead.org
>> CC: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> Changes in V14:
>>
>> - This is a new patch in the series
>>
>> arch/arm64/include/asm/kvm_host.h | 4 ++++
>> arch/arm64/kvm/debug.c | 6 +++++
>> arch/arm64/kvm/hyp/nvhe/debug-sr.c | 38 ++++++++++++++++++++++++++++++
>> 3 files changed, 48 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
>> index 68421c74283a..1faa0430d8dd 100644
>> --- a/arch/arm64/include/asm/kvm_host.h
>> +++ b/arch/arm64/include/asm/kvm_host.h
>> @@ -449,6 +449,8 @@ enum vcpu_sysreg {
>> CNTHV_CVAL_EL2,
>> PMSCR_EL1, /* Statistical profiling extension */
>> TRFCR_EL1, /* Self-hosted trace filters */
>> + BRBCR_EL1, /* Branch Record Buffer Control Register */
>> + BRBFCR_EL1, /* Branch Record Buffer Function Control Register */
>>
>> NR_SYS_REGS /* Nothing after this line! */
>> };
>> @@ -753,6 +755,8 @@ struct kvm_vcpu_arch {
>> #define VCPU_HYP_CONTEXT __vcpu_single_flag(iflags, BIT(7))
>> /* Save trace filter controls */
>> #define DEBUG_STATE_SAVE_TRFCR __vcpu_single_flag(iflags, BIT(8))
>> +/* Save BRBE context if active */
>> +#define DEBUG_STATE_SAVE_BRBE __vcpu_single_flag(iflags, BIT(9))
>>
>> /* 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 2ab41b954512..4055783c3d34 100644
>> --- a/arch/arm64/kvm/debug.c
>> +++ b/arch/arm64/kvm/debug.c
>> @@ -354,6 +354,11 @@ void kvm_arch_vcpu_load_debug_state_flags(struct kvm_vcpu *vcpu)
>> !(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) &&
>> + (read_sysreg_s(SYS_BRBCR_EL1) & (BRBCR_ELx_E0BRE | BRBCR_ELx_ExBRE)))
>> + vcpu_set_flag(vcpu, DEBUG_STATE_SAVE_BRBE);
>
> Isn't this supposed to just be the feature check? Whether BRBE is
> enabled or not is checked later in __debug_save_brbe() anyway.
Okay, will make it just a feature check via ID_AA64DFR0_EL1_BRBE_SHIFT.
>
> It seems like it's possible to become enabled after this flag load part.
Agreed.
>
>> }
>>
>> void kvm_arch_vcpu_put_debug_state_flags(struct kvm_vcpu *vcpu)
>> @@ -361,6 +366,7 @@ 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_TRFCR);
>> + vcpu_clear_flag(vcpu, DEBUG_STATE_SAVE_BRBE);
>> }
>>
>> void kvm_etm_set_guest_trfcr(u64 trfcr_guest)
>> diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
>> index 6174f710948e..e44a1f71a0f8 100644
>> --- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c
>> +++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
>> @@ -93,6 +93,38 @@ static void __debug_restore_trace(struct kvm_cpu_context *host_ctxt,
>> write_sysreg_s(ctxt_sys_reg(host_ctxt, TRFCR_EL1), SYS_TRFCR_EL1);
>> }
>>
>> +static void __debug_save_brbe(struct kvm_cpu_context *host_ctxt)
>> +{
>> + ctxt_sys_reg(host_ctxt, BRBCR_EL1) = 0;
>> + ctxt_sys_reg(host_ctxt, BRBFCR_EL1) = 0;
>> +
>> + /* Check if the BRBE is enabled */
>> + if (!(ctxt_sys_reg(host_ctxt, BRBCR_EL1) & (BRBCR_ELx_E0BRE | BRBCR_ELx_ExBRE)))
>> + return;
>
> Doesn't this always fail, the host BRBCR_EL1 value was just cleared on
> the line above.
Agreed, this error might have slipped in while converting to ctxt_sys_reg().
>
> Also, you need to read the register to determine if it was enabled or
Right
> not, so you might as well always store the real value, rather than 0 in
> the not enabled case.
But if it is not enabled - why store the real value ?
>
>> +
>> + /*
>> + * Prohibit branch record generation while we are in guest.
>> + * Since access to BRBCR_EL1 and BRBFCR_EL1 is trapped, the
>> + * guest can't modify the filtering set by the host.
>> + */
>> + ctxt_sys_reg(host_ctxt, BRBCR_EL1) = read_sysreg_s(SYS_BRBCR_EL1);
>> + ctxt_sys_reg(host_ctxt, BRBFCR_EL1) = read_sysreg_s(SYS_BRBFCR_EL1)
>> + write_sysreg_s(0, SYS_BRBCR_EL1);
>> + write_sysreg_s(0, SYS_BRBFCR_EL1);
>
> Why does SYS_BRBFCR_EL1 need to be saved and restored? Only
> BRBCR_ELx_E0BRE and BRBCR_ELx_ExBRE need to be cleared to disable BRBE.
Right, just thought both brbcr, and brbfcr system registers represent
current BRBE state (besides branch records), in a more comprehensive
manner, although none would be changed from inside the guest.
>
>> + isb();
>> +}
>> +
>> +static void __debug_restore_brbe(struct kvm_cpu_context *host_ctxt)
>> +{
>> + if (!ctxt_sys_reg(host_ctxt, BRBCR_EL1) || !ctxt_sys_reg(host_ctxt, BRBFCR_EL1))
>> + return;
>> +
>> + /* Restore BRBE controls */
>> + write_sysreg_s(ctxt_sys_reg(host_ctxt, BRBCR_EL1), SYS_BRBCR_EL1);
>> + write_sysreg_s(ctxt_sys_reg(host_ctxt, BRBFCR_EL1), SYS_BRBFCR_EL1);
>> + isb();
>> +}
>> +
>> void __debug_save_host_buffers_nvhe(struct kvm_cpu_context *host_ctxt,
>> struct kvm_cpu_context *guest_ctxt)
>> {
>> @@ -102,6 +134,10 @@ void __debug_save_host_buffers_nvhe(struct kvm_cpu_context *host_ctxt,
>>
>> if (vcpu_get_flag(host_ctxt->__hyp_running_vcpu, DEBUG_STATE_SAVE_TRFCR))
>> __debug_save_trace(host_ctxt, guest_ctxt);
>> +
>> + /* Disable BRBE branch records */
>> + if (vcpu_get_flag(host_ctxt->__hyp_running_vcpu, DEBUG_STATE_SAVE_BRBE))
>> + __debug_save_brbe(host_ctxt);
>> }
>>
>> void __debug_switch_to_guest(struct kvm_vcpu *vcpu)
>> @@ -116,6 +152,8 @@ void __debug_restore_host_buffers_nvhe(struct kvm_cpu_context *host_ctxt,
>> __debug_restore_spe(host_ctxt);
>> if (vcpu_get_flag(host_ctxt->__hyp_running_vcpu, DEBUG_STATE_SAVE_TRFCR))
>> __debug_restore_trace(host_ctxt, guest_ctxt);
>> + if (vcpu_get_flag(host_ctxt->__hyp_running_vcpu, DEBUG_STATE_SAVE_BRBE))
>> + __debug_restore_brbe(host_ctxt);
>> }
>>
>> void __debug_switch_to_host(struct kvm_vcpu *vcpu)
next prev parent reply other threads:[~2023-11-21 11:12 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-14 5:13 [V14 0/8] arm64/perf: Enable branch stack sampling Anshuman Khandual
2023-11-14 5:13 ` [V14 1/8] arm64/sysreg: Add BRBE registers and fields Anshuman Khandual
2023-11-14 5:13 ` [V14 2/8] KVM: arm64: Prevent guest accesses into BRBE system registers/instructions Anshuman Khandual
2023-11-14 5:13 ` [V14 3/8] drivers: perf: arm_pmuv3: Enable branch stack sampling framework Anshuman Khandual
2023-11-14 9:58 ` James Clark
2023-11-15 5:44 ` Anshuman Khandual
2023-11-15 9:37 ` James Clark
2023-11-21 9:13 ` Anshuman Khandual
2023-11-14 12:14 ` James Clark
2023-11-15 7:22 ` Anshuman Khandual
2023-11-15 10:07 ` James Clark
2023-11-21 9:57 ` Anshuman Khandual
2023-11-23 12:35 ` James Clark
2023-11-27 8:06 ` Anshuman Khandual
2023-11-14 17:10 ` James Clark
2023-11-30 3:58 ` Anshuman Khandual
2023-11-14 5:13 ` [V14 4/8] drivers: perf: arm_pmuv3: Enable branch stack sampling via FEAT_BRBE Anshuman Khandual
2023-11-14 12:11 ` James Clark
2023-11-21 10:47 ` Anshuman Khandual
2023-11-14 5:13 ` [V14 5/8] KVM: arm64: nvhe: Disable branch generation in nVHE guests Anshuman Khandual
2023-11-14 9:16 ` James Clark
2023-11-21 11:12 ` Anshuman Khandual [this message]
2023-11-23 13:54 ` James Clark
2023-11-27 8:25 ` Anshuman Khandual
2023-11-14 5:13 ` [V14 6/8] perf: test: Speed up running brstack test on an Arm model Anshuman Khandual
2023-11-14 5:13 ` [V14 7/8] perf: test: Remove empty lines from branch filter test output Anshuman Khandual
2023-11-14 5:13 ` [V14 8/8] perf: test: Extend branch stack sampling test for Arm64 BRBE Anshuman Khandual
2023-11-14 17:17 ` [V14 0/8] arm64/perf: Enable branch stack sampling James Clark
2023-11-22 5:15 ` Anshuman Khandual
2023-11-23 16:23 ` James Clark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20858eb9-a4d0-41be-ad1d-2a5f2d2fa0de@arm.com \
--to=anshuman.khandual@arm.com \
--cc=acme@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.clark@arm.com \
--cc=james.morse@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=mingo@redhat.com \
--cc=oliver.upton@linux.dev \
--cc=peterz@infradead.org \
--cc=robh@kernel.org \
--cc=suzuki.poulose@arm.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).