On Mon, Nov 28, 2022 at 06:52:22PM +0000, Vincent Donnefort wrote:
From: Marc Zyngier maz@kernel.org
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@kernel.org/ Link: https://lore.kernel.org/r/20221011165400.1241729-1-maz@kernel.org/ Cc: stable@vger.kernel.org # 5.15+ Reported-by: Vincent Donnefort vdonnefort@google.com Signed-off-by: Marc Zyngier maz@kernel.org Tested-by: Vincent Donnefort vdonnefort@google.com [Vincent: Add a paragraph about why this patch is for stable only] Signed-off-by: Vincent Donnefort vdonnefort@google.com
Now queued up, thanks.
greg k-h