summaryrefslogtreecommitdiff
path: root/scripts/gdb/linux/stackdepot.py
diff options
context:
space:
mode:
authorAlexandru Elisei <alexandru.elisei@arm.com>2025-09-02 14:08:32 +0100
committerOliver Upton <oliver.upton@linux.dev>2025-09-10 02:56:19 -0700
commitefad60e4605721b829a49bcaa6afc517a80a7247 (patch)
tree70457300cf1ce6e2e7622c0a4d45efca99f8179d /scripts/gdb/linux/stackdepot.py
parent860b21c31d16f99b8c37b77993682f7bc8c211d7 (diff)
KVM: arm64: Initialize PMSCR_EL1 when in VHE
According to the pseudocode for StatisticalProfilingEnabled() from Arm DDI0487L.b, PMSCR_EL1 controls profiling at EL1 and EL0: - PMSCR_EL1.E1SPE controls profiling at EL1. - PMSCR_EL1.E0SPE controls profiling at EL0 if HCR_EL2.TGE=0. These two fields reset to UNKNOWN values. When KVM runs in VHE mode and profiling is enabled in the host, before entering a guest, KVM does not touch any of the SPE registers, leaving the buffer enabled, and it clears HCR_EL2.TGE. As a result, depending on the reset value for the E1SPE and E0SPE fields, KVM might unintentionally profile a guest. Make the behaviour consistent and predictable by clearing PMSCR_EL1 when KVM initialises the host debug configuration. Note that this is not a problem for nVHE, because KVM clears PMSCR_EL1.{E1SPE,E0SPE} before entering the guest. Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com> Link: https://lore.kernel.org/r/20250902130833.338216-2-alexandru.elisei@arm.com Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Diffstat (limited to 'scripts/gdb/linux/stackdepot.py')
0 files changed, 0 insertions, 0 deletions