aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/bin/export-to-postgresql-report
diff options
context:
space:
mode:
authorOliver Upton <[email protected]>2023-07-13 22:16:49 +0000
committerOliver Upton <[email protected]>2023-07-14 23:28:58 +0000
commit6d4f9236cd678e0bf0c09fd0e1fa20435bb2e5a2 (patch)
tree558cec65eb773cc3f502dcd9bab66ff98ab168b7 /tools/perf/scripts/python/bin/export-to-postgresql-report
parentb321c31c9b7b309dcde5e8854b741c8e6a9a05f0 (diff)
KVM: arm64: Correctly handle RES0 bits PMEVTYPER<n>_EL0.evtCount
The PMU event ID varies from 10 to 16 bits, depending on the PMU version. If the PMU only supports 10 bits of event ID, bits [15:10] of the evtCount field behave as RES0. While the actual PMU emulation code gets this right (i.e. RES0 bits are masked out when programming the perf event), the sysreg emulation writes an unmasked value to the in-memory cpu context. The net effect is that guest reads and writes of PMEVTYPER<n>_EL0 will see non-RES0 behavior in the reserved bits of the field. As it so happens, kvm_pmu_set_counter_event_type() already writes a masked value to the in-memory context that gets overwritten by access_pmu_evtyper(). Fix the issue by removing the unnecessary (and incorrect) register write in access_pmu_evtyper(). Reviewed-by: Marc Zyngier <[email protected]> Reviewed-by: Reiji Watanabe <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Oliver Upton <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/bin/export-to-postgresql-report')
0 files changed, 0 insertions, 0 deletions