Re: arm64 regression in kernel 5.12 related to the (n)VHE

From: Marc Zyngier <maz@kernel.org>
To: "Rafał Miłecki" <zajec5@gmail.com>
Cc: David Brazdil <dbrazdil@google.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Ard Biesheuvel <ardb@kernel.org>, Marco Elver <elver@google.com>,
	BCM Kernel Feedback <bcm-kernel-feedback-list@broadcom.com>,
	Florian Fainelli <f.fainelli@gmail.com>
Subject: Re: arm64 regression in kernel 5.12 related to the (n)VHE
Date: Thu, 12 Aug 2021 09:24:17 +0100	[thread overview]
Message-ID: <877dgr9iku.wl-maz@kernel.org> (raw)
In-Reply-To: <7fee376c-2099-6d88-0be8-ba57633e0965@gmail.com>

On Thu, 12 Aug 2021 08:56:57 +0100,
Rafał Miłecki <zajec5@gmail.com> wrote:
> 
> On 12.08.2021 09:32, Rafał Miłecki wrote:
> > (Unless it's a false conclusion and CONFIG_KVM just breaks console
> > somehow)
> 
> That was a false conclusion. I modified kernel/printk/printk.c and set
> keep_bootcon = 1
> 
> A full log with important part below:

[...]

> kernel BUG at arch/arm64/kernel/traps.c:406!
> Internal error: Oops - BUG: 0 [#1] SMP
> CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.11.22-g0453a426c37b-dirty #12
> Hardware name: Asus GT-AC5300 (DT)
> pstate: 00000085 (nzcv daIf -PAN -UAO -TCO BTYPE=--)
> pc : do_undefinstr+0x204/0x230
> lr : do_undefinstr+0x218/0x230
> sp : ffffffc01001bcc0
> x29: ffffffc01001bcc0 x28: ffffff80010a0a80
> x27: 00000000000000e0 x26: ffffffc01001c000
> x25: ffffffc010018000 x24: ffffffc0108a9000
> x23: 0000000080000085 x22: 00000000d4000002
> x21: ffffffc0108cd0d8 x20: ffffff80010a0a80
> x19: ffffffc01001bd40 x18: 0000000000000030
> x17: fbfffafbffffffff x16: 0000000000000048
> x15: 0000046366960998 x14: 0000000000000017
> x13: 0000000000000001 x12: 0000000000000001
> x11: 0000000000000000 x10: 0000000000000003
> x9 : 0000000000000000 x8 : 0000000000000000
> x7 : ffffff803fde8600 x6 : 0000000000000001
> x5 : 0000000000000000 x4 : ffffff80010a0a80
> x3 : 00000000d5300000 x2 : ffffffc01082ce68
> x1 : ffffffc0108cd0e8 x0 : 0000000080000085
> Call trace:
>  do_undefinstr+0x204/0x230
>  el1_undef+0x30/0x50
>  el1_sync_handler+0x8c/0xd0
>  el1_sync+0x78/0x100
>  __hyp_reset_vectors+0x4/0x91d0
>  _kvm_arch_hardware_enable+0x3c/0x60

And here's the proof. The first HVC we issue ends up generating an
UNDEF, and the kernel legitimately panics. It is just that from 5.12,
we always use HVC even if you don't have KVM enabled. Or kexec. Or
anything else that requires jumping back to EL2, despite having booted
at... EL2. Nonsense.

I'll have to go and think of how to handle this. This may end-up being
a command-line option if we cannot easily handle the UNDEF that early
at boot time.

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel