diff options
author | Will Deacon <will@kernel.org> | 2024-05-01 19:34:00 +0300 |
---|---|---|
committer | Marc Zyngier <maz@kernel.org> | 2024-05-08 09:05:53 +0300 |
commit | 5053c3f0519cd4c746577e3a6a7756f7c04b03dd (patch) | |
tree | 6adbd4db6ee17a071dfcae4325985ef15f74ddee /tools/perf/scripts/python/stackcollapse.py | |
parent | 3c142f9d02b992aec5d96b82917e4cc07850c4df (diff) | |
download | linux-5053c3f0519cd4c746577e3a6a7756f7c04b03dd.tar.xz |
KVM: arm64: Use hVHE in pKVM by default on CPUs with VHE support
The early command line parsing treats "kvm-arm.mode=protected" as an
alias for "id_aa64mmfr1.vh=0", forcing the use of nVHE so that the host
kernel runs at EL1 with the pKVM hypervisor at EL2.
With the introduction of hVHE support in ad744e8cb346 ("arm64: Allow
arm64_sw.hvhe on command line"), the hypervisor can run using the EL2+0
translation regime. This is interesting for unusual CPUs that have VH
stuck to 1, but also because it opens the possibility of a hypervisor
"userspace" in the distant future which could be used to isolate vCPU
contexts in the hypervisor (see Marc's talk from KVM Forum 2022 [1]).
Repaint the "kvm-arm.mode=protected" alias to map to "arm64_sw.hvhe=1",
which will use hVHE on CPUs that support it and remain with nVHE
otherwise.
[1] https://www.youtube.com/watch?v=1F_Mf2j9eIo
Signed-off-by: Will Deacon <will@kernel.org>
Acked-by: Oliver Upton <oliver.upton@linux.dev>
Link: https://lore.kernel.org/r/20240501163400.15838-3-will@kernel.org
Signed-off-by: Marc Zyngier <maz@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/stackcollapse.py')
0 files changed, 0 insertions, 0 deletions