KVM: arm64: Use hVHE in pKVM by default on CPUs with VHE support
authorWill Deacon <will@kernel.org>
Wed, 1 May 2024 16:34:00 +0000 (17:34 +0100)
committerMarc Zyngier <maz@kernel.org>
Wed, 8 May 2024 06:05:53 +0000 (07:05 +0100)
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>
arch/arm64/kernel/pi/idreg-override.c

index 39c9253fcf23f74eee51025fdd64ffef4aadd764..c20549e43a7739ee780e41f6029e876e6f28121e 100644 (file)
@@ -210,7 +210,7 @@ static const struct {
        char    feature[FTR_ALIAS_OPTION_LEN];
 } aliases[] __initconst = {
        { "kvm_arm.mode=nvhe",          "arm64_sw.hvhe=0 id_aa64mmfr1.vh=0" },
-       { "kvm_arm.mode=protected",     "id_aa64mmfr1.vh=0" },
+       { "kvm_arm.mode=protected",     "arm64_sw.hvhe=1" },
        { "arm64.nosve",                "id_aa64pfr0.sve=0" },
        { "arm64.nosme",                "id_aa64pfr1.sme=0" },
        { "arm64.nobti",                "id_aa64pfr1.bt=0" },