Re: [PATCH] KVM: arm64: Drop %pB on nVHE panic when stage-2 is active

On Fri, 31 Jul 2026 at 19:39, <[email protected]> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issu=
e(s) to consider:
>
> Pre-existing issues:
> - [High] The patch fixes a stage-2 fault deadlock in `print_nvhe_hyp_pani=
c()` by removing the `%pB` modifier, but misses `kvm_nvhe_dump_backtrace_en=
try()` and `dump_kernel_instr()` which both access lazily-mapped host memor=
y later in the exact same panic path, causing the same deadlock.

I don't think either deadlocks. dump_kernel_instr() reads hyp .text,
which is kept RO-mapped in the host stage-2 for panic inspection
(fix_host_ownership_walker(), PAGE_HYP_EXEC ->
host_stage2_idmap_locked(..., PROT_R)), so no fault.
kvm_nvhe_dump_backtrace_entry()'s %pB runs only under
CONFIG_PKVM_STACKTRACE, which depends on PKVM_DISABLE_STAGE2_ON_PANIC,
and that path disables the host stage-2 on panic anyway; otherwise
it's the stub, and non-protected has no host stage-2. kallsyms was the
only lazily-mapped access, so I think this is complete.

/fuad

> --
>
> --- Patch [1]: [PATCH] KVM: arm64: Drop %pB on nVHE panic when stage-2 is=
 active ---
> commit cbd94a7b340a7dc4be01336a040cb8c3d9690ab4
> Author: Vincent Donnefort <[email protected]>
>
> KVM: arm64: Drop %pB on nVHE panic when stage-2 is active
>
> This commit removes the %pB format specifier from print_nvhe_hyp_panic()
> when running in protected KVM mode without stage-2 panic disabling. This
> prevents a deadlock caused by a stage-2 fault when accessing unmapped
> kallsyms memory while the host stage-2 lock is held.
>
> > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.=
c
> > index 54aedf93c78b6..2e1951c215ae8 100644
> > --- a/arch/arm64/kvm/handle_exit.c
> > +++ b/arch/arm64/kvm/handle_exit.c
> > @@ -509,8 +509,12 @@ void handle_exit_early(struct kvm_vcpu *vcpu, int =
exception_index)
> >
> >  static void print_nvhe_hyp_panic(const char *name, u64 panic_addr)
> >  {
> > -     kvm_err("nVHE hyp %s at: [<%016llx>] %pB!\n", name, panic_addr,
> > -             (void *)(panic_addr + kaslr_offset()));
> > +     /* Kallsyms might not be mapped in the host stage-2 */
> > +     if (is_protected_kvm_enabled() && !IS_ENABLED(CONFIG_PKVM_DISABLE=
_STAGE2_ON_PANIC))
> > +             kvm_err("nVHE hyp %s at: %016llx!\n", name, panic_addr);
> > +     else
> > +             kvm_err("nVHE hyp %s at: [<%016llx>] %pB!\n", name, panic=
_addr,
> > +                     (void *)(panic_addr + kaslr_offset()));
> >  }
>
> [Severity: High]
> This is a pre-existing issue, but does this same deadlock still trigger
> later in the panic path?
>
> While this fixes the memory access in print_nvhe_hyp_panic(), the handler
> nvhe_hyp_panic_handler() subsequently calls kvm_nvhe_dump_backtrace() and
> dump_kernel_instr().
>
> In arch/arm64/kvm/stacktrace.c:kvm_nvhe_dump_backtrace_entry(), there is
> another use of %pB:
>
>         kvm_err(" [<%016lx>] %pB\n", where, (void *)(where + kaslr_offset=
()));
>
> Additionally, nvhe_hyp_panic_handler() calls dump_kernel_instr() which al=
so
> reads the faulting instruction directly from memory in
> arch/arm64/kernel/traps.c:
>
>         bad =3D aarch64_insn_read(&((u32 *)kaddr)[i], &val);
>
> Will both of these also access lazily-mapped host stage-2 memory, trigger
> a stage-2 data abort, and deadlock when trying to re-acquire host_mmu.loc=
k?
>
> --
> Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260731182231.12=
[email protected]?part=3D1
>