Date: Wed, 10 Apr 2024 13:58:55 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 277559] kldload vmm sometimes hangs kernel on arm64 Message-ID: <bug-277559-27103-7Z4vLK1mLv@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-277559-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-277559-27103@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277559 Mark Johnston <markj@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |markj@FreeBSD.org Status|New |Open --- Comment #4 from Mark Johnston <markj@FreeBSD.org> --- vmmops_modinit() is using smp_rendezvous to execute code (arm_setup_vectors= ()) on each CPU. Presumably one or more of the CPUs is hanging in the vmm_call_hyp() call which initializes per-CPU state (various control regist= ers) in EL2. This is done in handle_hyp_init in vmm_hyp_exception.S. The first thing that routine does is initialize the vector table; I wonder = if that should be done last instead. Perhaps there is a stray EL2 exception occurring for some reason? It would be useful to add printf("%d", curcpu)s around the vmm_call_hyp() c= alls in arm_setup_vectors() to see if there is a pattern to the hangs. We can a= lso try modifying vmm_call_hyp() to return early after various points, so as to= try and narrow down exactly where the hang is happening. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-277559-27103-7Z4vLK1mLv>