On Mon, Nov 28, 2022 at 06:19:15PM +0100, Greg KH wrote: > On Mon, Nov 28, 2022 at 04:21:28PM +0000, Vincent Donnefort wrote: > > On Tue, Nov 08, 2022 at 10:01:38AM +0000, Vincent Donnefort wrote: > > > 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. > > > > > > Cc: <stable@xxxxxxxxxxxxxxx> # 5.15+ > > > Reported-by: Vincent Donnefort <vdonnefort@xxxxxxxxxx> > > > Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx> > > > Tested-by: Vincent Donnefort <vdonnefort@xxxxxxxxxx> > > > > > > --- > > > > > > This patch doesn't have an upstream version. It's been fixed by the side > > > effect of another upstream patch. see conversation [1] > > > > > > [1] https://lore.kernel.org/all/20221011165400.1241729-1-maz@xxxxxxxxxx/ > > > > > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c > > > index 4cb265e15361..3fe816c244ce 100644 > > > --- a/arch/arm64/kvm/arm.c > > > +++ b/arch/arm64/kvm/arm.c > > > @@ -2000,6 +2000,17 @@ static int pkvm_drop_host_privileges(void) > > > * 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; > > > } > > > -- > > > 2.38.1.431.g37b22c650d-goog > > > > > > > Hi Greg, > > > > Any chance to pick this fix for 5.15? > > <formletter> > > This is not the correct way to submit patches for inclusion in the > stable kernel tree. Please read: > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html > for how to do this properly. > > </formletter> Sadly this patch doesn't have an upstream version equivalent. The reason is it's been fixed as a side effect of another feature introduction, hence the stable-only fix made by Marc. [1] Not sure how to handle that case.
