This is a note to let you know that I've just added the patch titled
KVM: arm64: pkvm: Fixup boot mode to reflect that the kernel resumes from EL1
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
kvm-arm64-pkvm-fixup-boot-mode-to-reflect-that-the-kernel-resumes-from-el1.patch
and it can be found in the queue-5.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From vdonnefort@xxxxxxxxxx Tue Nov 29 17:52:03 2022
From: Vincent Donnefort <vdonnefort@xxxxxxxxxx>
Date: Mon, 28 Nov 2022 18:52:22 +0000
Subject: KVM: arm64: pkvm: Fixup boot mode to reflect that the kernel resumes from EL1
To: gregkh@xxxxxxxxxx
Cc: kernel-team@xxxxxxxxxxx, Marc Zyngier <maz@xxxxxxxxxx>, stable@xxxxxxxxxxxxxxx, Vincent Donnefort <vdonnefort@xxxxxxxxxx>
Message-ID: <20221128185222.1291038-1-vdonnefort@xxxxxxxxxx>
From: Marc Zyngier <maz@xxxxxxxxxx>
The kernel has an awfully complicated boot sequence in order to cope
with the various EL2 configurations, including those that "enhanced"
the architecture. We go from EL2 to EL1, then back to EL2, staying
at EL2 if VHE capable and otherwise go back to EL1.
Here's a paracetamol tablet for you.
The cpu_resume path follows the same logic, because coming up with
two versions of a square wheel is hard.
However, things aren't this straightforward with pKVM, as the host
resume path is always proxied by the hypervisor, which means that
the kernel is always entered at EL1. Which contradicts what the
__boot_cpu_mode[] array contains (it obviously says EL2).
This thus triggers a HVC call from EL1 to EL2 in a vain attempt
to upgrade from EL1 to EL2 VHE, which we are, funnily enough,
reluctant to grant to the host kernel. This is also completely
unexpected, and puzzles your average EL2 hacker.
Address it by fixing up the boot mode at the point the host gets
deprivileged. is_hyp_mode_available() and co already have a static
branch to deal with this, making it pretty safe.
This stable fix doesn't have an upstream version. The entire bootflow
has been reworked from 6.0 and that fixed the boot mode at the same
time, from commit 005e12676af0 ("arm64: head: record CPU boot mode after
enabling the MMU") to be precise. However, the latter is part of a 20
patches long series and can't be simply cherry-pick'ed.
Link: https://lore.kernel.org/r/20220624150651.1358849-1-ardb@xxxxxxxxxx/
Link: https://lore.kernel.org/r/20221011165400.1241729-1-maz@xxxxxxxxxx/
Cc: <stable@xxxxxxxxxxxxxxx> # 5.15+
Reported-by: Vincent Donnefort <vdonnefort@xxxxxxxxxx>
Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx>
Tested-by: Vincent Donnefort <vdonnefort@xxxxxxxxxx>
[Vincent: Add a paragraph about why this patch is for stable only]
Signed-off-by: Vincent Donnefort <vdonnefort@xxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
arch/arm64/kvm/arm.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -2000,6 +2000,17 @@ static int pkvm_drop_host_privileges(voi
* once the host stage 2 is installed.
*/
static_branch_enable(&kvm_protected_mode_initialized);
+
+ /*
+ * Fixup the boot mode so that we don't take spurious round
+ * trips via EL2 on cpu_resume. Flush to the PoC for a good
+ * measure, so that it can be observed by a CPU coming out of
+ * suspend with the MMU off.
+ */
+ __boot_cpu_mode[0] = __boot_cpu_mode[1] = BOOT_CPU_MODE_EL1;
+ dcache_clean_poc((unsigned long)__boot_cpu_mode,
+ (unsigned long)(__boot_cpu_mode + 2));
+
on_each_cpu(_kvm_host_prot_finalize, &ret, 1);
return ret;
}
Patches currently in stable-queue which might be from vdonnefort@xxxxxxxxxx are
queue-5.15/kvm-arm64-pkvm-fixup-boot-mode-to-reflect-that-the-kernel-resumes-from-el1.patch
