aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/export-to-sqlite.py
diff options
context:
space:
mode:
authorMark Rutland <[email protected]>2020-02-21 14:50:22 +0000
committerCatalin Marinas <[email protected]>2020-03-13 17:34:28 +0000
commitb5475d8caedb71476f999a858ea3f8c24c5f9e50 (patch)
tree7a46098e055c0f1a206ff4e5bea0632943ca9e7c /tools/perf/scripts/python/export-to-sqlite.py
parent1db5cdeccd813330aaab19b3fccab15e1d07fe12 (diff)
arm64: kvm: hyp: use cpus_have_final_cap()
The KVM hyp code is only run after system capabilities have been finalized, and thus all const cap checks have been patched. This is noted in in __cpu_init_hyp_mode(), where we BUG() if called too early: | /* | * Call initialization code, and switch to the full blown HYP code. | * If the cpucaps haven't been finalized yet, something has gone very | * wrong, and hyp will crash and burn when it uses any | * cpus_have_const_cap() wrapper. | */ Given this, the hyp code can use cpus_have_final_cap() and avoid generating code to check the cpu_hwcaps array, which would be unsafe to run in hyp context. This patch migrate the KVM hyp code to cpus_have_final_cap(), avoiding this redundant code generation, and making it possible to detect if we accidentally invoke this code too early. In the latter case, the BUG() in cpus_have_final_cap() will cause a hyp panic. Signed-off-by: Mark Rutland <[email protected]> Reviewed-by: Marc Zyngier <[email protected]> Cc: James Morse <[email protected]> Cc: Julien Thierry <[email protected]> Cc: Suzuki Poulouse <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/export-to-sqlite.py')
0 files changed, 0 insertions, 0 deletions