From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by smtp.lore.kernel.org (Postfix) with ESMTP id 354A0C433EF for ; Thu, 21 Jul 2022 20:35:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 90BD44C74B; Thu, 21 Jul 2022 16:35:34 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@linux.dev Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XraGEw043jVj; Thu, 21 Jul 2022 16:35:33 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 2C4AD4C76A; Thu, 21 Jul 2022 16:35:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 1B5904C73E for ; Thu, 21 Jul 2022 16:35:32 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5b1Fe9BH5bc for ; Thu, 21 Jul 2022 16:35:30 -0400 (EDT) Received: from out0.migadu.com (out0.migadu.com [94.23.1.103]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id BEBCF4C709 for ; Thu, 21 Jul 2022 16:35:30 -0400 (EDT) Date: Thu, 21 Jul 2022 21:35:26 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1658435729; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xf2R3DLEoWV9wiDF/EeEI67ekf5B8ETj3Ae3cglXYTQ=; b=LCKVjwVeX3h/LJlm5Q+ZVxAzI8OGSt1gtNMfTIM4zhBrh5K1BJZzOdYuc11fL+2sF8I9gW ugooAwV9bAtpkfjd76uA/0VU+Koxl64lmoPFPLAGjMAUCJI5gkk7aYlq12L+8GFShHbZOX KUWvcVNrv3UBsznTETFsyIURS6u06QQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Kalesh Singh Subject: Re: [PATCH v5 17/17] KVM: arm64: Introduce hyp_dump_backtrace() Message-ID: References: <20220721055728.718573-1-kaleshsingh@google.com> <20220721055728.718573-18-kaleshsingh@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220721055728.718573-18-kaleshsingh@google.com> X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev Cc: wangkefeng.wang@huawei.com, catalin.marinas@arm.com, elver@google.com, vincenzo.frascino@arm.com, will@kernel.org, android-mm@google.com, maz@kernel.org, kvmarm@lists.cs.columbia.edu, madvenka@linux.microsoft.com, kernel-team@android.com, drjones@redhat.com, ast@kernel.org, broonie@kernel.org, linux-arm-kernel@lists.infradead.org, andreyknvl@gmail.com, linux-kernel@vger.kernel.org, mhiramat@kernel.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu Hi Kalesh, Nifty series! Had the chance to take it for a spin :) Few comments below: On Wed, Jul 20, 2022 at 10:57:28PM -0700, Kalesh Singh wrote: > In non-protected nVHE mode, unwinds and dumps the hypervisor backtrace > from EL1. This is possible beacuase the host can directly access the > hypervisor stack pages in non-proteced mode. > > Signed-off-by: Kalesh Singh > --- > > Changes in v5: > - Move code out from nvhe.h header to handle_exit.c, per Marc > - Fix stacktrace symoblization when CONFIG_RAMDOMIZE_BASE is enabled, > per Fuad > - Use regular comments instead of doc comments, per Fuad > > arch/arm64/kvm/handle_exit.c | 65 +++++++++++++++++++++++++++++++----- > 1 file changed, 56 insertions(+), 9 deletions(-) > > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c > index ad568da5c7d7..432b6b26f4ad 100644 > --- a/arch/arm64/kvm/handle_exit.c > +++ b/arch/arm64/kvm/handle_exit.c [...] > @@ -318,6 +319,56 @@ void handle_exit_early(struct kvm_vcpu *vcpu, int exception_index) > kvm_handle_guest_serror(vcpu, kvm_vcpu_get_esr(vcpu)); > } > > +/* > + * kvm_nvhe_print_backtrace_entry - Symbolizes and prints the HYP stack address > + */ > +static void kvm_nvhe_print_backtrace_entry(unsigned long addr, > + unsigned long hyp_offset) > +{ > + unsigned long va_mask = GENMASK_ULL(vabits_actual - 1, 0); > + > + /* Mask tags and convert to kern addr */ > + addr = (addr & va_mask) + hyp_offset; > + kvm_err(" [<%016lx>] %pB\n", addr, (void *)(addr + kaslr_offset())); > +} It is a bit odd to see this get churned from the last patch. Is it possible to introduce the helper earlier on? In fact, the non-protected patch should come first to layer the series better. Also, it seems to me that there isn't much need for the indirection if the pKVM unwinder is made to work around the below function signature: > +/* > + * hyp_dump_backtrace_entry - Dump an entry of the non-protected nVHE HYP stacktrace > + * > + * @arg : the hypervisor offset, used for address translation > + * @where : the program counter corresponding to the stack frame > + */ > +static bool hyp_dump_backtrace_entry(void *arg, unsigned long where) > +{ > + kvm_nvhe_print_backtrace_entry(where, (unsigned long)arg); > + > + return true; > +} > +/* > + * hyp_dump_backtrace - Dump the non-proteced nVHE HYP backtrace. > + * > + * @hyp_offset: hypervisor offset, used for address translation. > + * > + * The host can directly access HYP stack pages in non-protected > + * mode, so the unwinding is done directly from EL1. This removes > + * the need for shared buffers between host and hypervisor for > + * the stacktrace. > + */ > +static void hyp_dump_backtrace(unsigned long hyp_offset) > +{ > + struct kvm_nvhe_stacktrace_info *stacktrace_info; > + struct unwind_state state; > + > + stacktrace_info = this_cpu_ptr_nvhe_sym(kvm_stacktrace_info); > + > + kvm_nvhe_unwind_init(&state, stacktrace_info->fp, stacktrace_info->pc); > + > + kvm_err("Non-protected nVHE HYP call trace:\n"); I don't see the value in discerning non-protected vs. protected in the preamble, as panic() will dump the kernel commandline which presumably would have a `kvm-arm.mode=protected` in the case of pKVM. Not entirely your problem, but we should really use a consistent name for that thing we have living at EL2. Hyp or nVHE (but not both) would be appropriate. > + unwind(&state, hyp_dump_backtrace_entry, (void *)hyp_offset); > + kvm_err("---- End of Non-protected nVHE HYP call trace ----\n"); Maybe: kvm_err("---[ end ${NAME_FOR_EL2} trace ]---"); (more closely matches the pattern of the arm64 stacktrace) -- Thanks, Oliver _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 24788C43334 for ; Thu, 21 Jul 2022 20:36:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=fPUjSnS9fn23ufWKKZpJgh5lmoKZ0mFAnKmMTYJxw+0=; b=sm66xxvodXYg/r 9dGGWHnCSuaZ8k7SFr3blQOcBvNWvcs8jTHxMgZI6L87QwXWNUfhK7y7yvEzGjB8YWLhkPLCU29XB IGRofrRMwrhjbQyhDBW46z8nAwlMMmMdCQCX+yn4CC7W6jD6y07ESwkfQ63ybbRYdOgk1rEUpE4TG fyjdPH4mkytMLsHBKna/nCrzSQbxGkeWl4HRPBtp8UBfOYEhz9naVoS23EmMJQx3NJReSNCF7kBSH nB4qgxP2yoeCXRqv/4/rJqHBQUvhg5XEJbSF1VGl9ZU8ScRNoNuYB5H3CUWCTe10DfBT/VOEP+jXA Afsu6ZxldFTCMxs+srSA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oEctY-00CCnI-Cl; Thu, 21 Jul 2022 20:35:40 +0000 Received: from out0.migadu.com ([2001:41d0:2:267::]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oEctV-00CCk3-0M for linux-arm-kernel@lists.infradead.org; Thu, 21 Jul 2022 20:35:38 +0000 Date: Thu, 21 Jul 2022 21:35:26 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1658435729; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xf2R3DLEoWV9wiDF/EeEI67ekf5B8ETj3Ae3cglXYTQ=; b=LCKVjwVeX3h/LJlm5Q+ZVxAzI8OGSt1gtNMfTIM4zhBrh5K1BJZzOdYuc11fL+2sF8I9gW ugooAwV9bAtpkfjd76uA/0VU+Koxl64lmoPFPLAGjMAUCJI5gkk7aYlq12L+8GFShHbZOX KUWvcVNrv3UBsznTETFsyIURS6u06QQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Kalesh Singh Cc: maz@kernel.org, mark.rutland@arm.com, broonie@kernel.org, madvenka@linux.microsoft.com, tabba@google.com, will@kernel.org, qperret@google.com, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, andreyknvl@gmail.com, vincenzo.frascino@arm.com, mhiramat@kernel.org, ast@kernel.org, drjones@redhat.com, wangkefeng.wang@huawei.com, elver@google.com, keirf@google.com, yuzenghui@huawei.com, ardb@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, android-mm@google.com, kernel-team@android.com Subject: Re: [PATCH v5 17/17] KVM: arm64: Introduce hyp_dump_backtrace() Message-ID: References: <20220721055728.718573-1-kaleshsingh@google.com> <20220721055728.718573-18-kaleshsingh@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220721055728.718573-18-kaleshsingh@google.com> X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220721_133537_466188_37C71E35 X-CRM114-Status: GOOD ( 24.88 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Kalesh, Nifty series! Had the chance to take it for a spin :) Few comments below: On Wed, Jul 20, 2022 at 10:57:28PM -0700, Kalesh Singh wrote: > In non-protected nVHE mode, unwinds and dumps the hypervisor backtrace > from EL1. This is possible beacuase the host can directly access the > hypervisor stack pages in non-proteced mode. > > Signed-off-by: Kalesh Singh > --- > > Changes in v5: > - Move code out from nvhe.h header to handle_exit.c, per Marc > - Fix stacktrace symoblization when CONFIG_RAMDOMIZE_BASE is enabled, > per Fuad > - Use regular comments instead of doc comments, per Fuad > > arch/arm64/kvm/handle_exit.c | 65 +++++++++++++++++++++++++++++++----- > 1 file changed, 56 insertions(+), 9 deletions(-) > > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c > index ad568da5c7d7..432b6b26f4ad 100644 > --- a/arch/arm64/kvm/handle_exit.c > +++ b/arch/arm64/kvm/handle_exit.c [...] > @@ -318,6 +319,56 @@ void handle_exit_early(struct kvm_vcpu *vcpu, int exception_index) > kvm_handle_guest_serror(vcpu, kvm_vcpu_get_esr(vcpu)); > } > > +/* > + * kvm_nvhe_print_backtrace_entry - Symbolizes and prints the HYP stack address > + */ > +static void kvm_nvhe_print_backtrace_entry(unsigned long addr, > + unsigned long hyp_offset) > +{ > + unsigned long va_mask = GENMASK_ULL(vabits_actual - 1, 0); > + > + /* Mask tags and convert to kern addr */ > + addr = (addr & va_mask) + hyp_offset; > + kvm_err(" [<%016lx>] %pB\n", addr, (void *)(addr + kaslr_offset())); > +} It is a bit odd to see this get churned from the last patch. Is it possible to introduce the helper earlier on? In fact, the non-protected patch should come first to layer the series better. Also, it seems to me that there isn't much need for the indirection if the pKVM unwinder is made to work around the below function signature: > +/* > + * hyp_dump_backtrace_entry - Dump an entry of the non-protected nVHE HYP stacktrace > + * > + * @arg : the hypervisor offset, used for address translation > + * @where : the program counter corresponding to the stack frame > + */ > +static bool hyp_dump_backtrace_entry(void *arg, unsigned long where) > +{ > + kvm_nvhe_print_backtrace_entry(where, (unsigned long)arg); > + > + return true; > +} > +/* > + * hyp_dump_backtrace - Dump the non-proteced nVHE HYP backtrace. > + * > + * @hyp_offset: hypervisor offset, used for address translation. > + * > + * The host can directly access HYP stack pages in non-protected > + * mode, so the unwinding is done directly from EL1. This removes > + * the need for shared buffers between host and hypervisor for > + * the stacktrace. > + */ > +static void hyp_dump_backtrace(unsigned long hyp_offset) > +{ > + struct kvm_nvhe_stacktrace_info *stacktrace_info; > + struct unwind_state state; > + > + stacktrace_info = this_cpu_ptr_nvhe_sym(kvm_stacktrace_info); > + > + kvm_nvhe_unwind_init(&state, stacktrace_info->fp, stacktrace_info->pc); > + > + kvm_err("Non-protected nVHE HYP call trace:\n"); I don't see the value in discerning non-protected vs. protected in the preamble, as panic() will dump the kernel commandline which presumably would have a `kvm-arm.mode=protected` in the case of pKVM. Not entirely your problem, but we should really use a consistent name for that thing we have living at EL2. Hyp or nVHE (but not both) would be appropriate. > + unwind(&state, hyp_dump_backtrace_entry, (void *)hyp_offset); > + kvm_err("---- End of Non-protected nVHE HYP call trace ----\n"); Maybe: kvm_err("---[ end ${NAME_FOR_EL2} trace ]---"); (more closely matches the pattern of the arm64 stacktrace) -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4BC39C43334 for ; Thu, 21 Jul 2022 20:35:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231857AbiGUUfe (ORCPT ); Thu, 21 Jul 2022 16:35:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33336 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229754AbiGUUfd (ORCPT ); Thu, 21 Jul 2022 16:35:33 -0400 Received: from out0.migadu.com (out0.migadu.com [IPv6:2001:41d0:2:267::]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DFEE32CDD7 for ; Thu, 21 Jul 2022 13:35:30 -0700 (PDT) Date: Thu, 21 Jul 2022 21:35:26 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1658435729; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=xf2R3DLEoWV9wiDF/EeEI67ekf5B8ETj3Ae3cglXYTQ=; b=LCKVjwVeX3h/LJlm5Q+ZVxAzI8OGSt1gtNMfTIM4zhBrh5K1BJZzOdYuc11fL+2sF8I9gW ugooAwV9bAtpkfjd76uA/0VU+Koxl64lmoPFPLAGjMAUCJI5gkk7aYlq12L+8GFShHbZOX KUWvcVNrv3UBsznTETFsyIURS6u06QQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Kalesh Singh Cc: maz@kernel.org, mark.rutland@arm.com, broonie@kernel.org, madvenka@linux.microsoft.com, tabba@google.com, will@kernel.org, qperret@google.com, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, andreyknvl@gmail.com, vincenzo.frascino@arm.com, mhiramat@kernel.org, ast@kernel.org, drjones@redhat.com, wangkefeng.wang@huawei.com, elver@google.com, keirf@google.com, yuzenghui@huawei.com, ardb@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, android-mm@google.com, kernel-team@android.com Subject: Re: [PATCH v5 17/17] KVM: arm64: Introduce hyp_dump_backtrace() Message-ID: References: <20220721055728.718573-1-kaleshsingh@google.com> <20220721055728.718573-18-kaleshsingh@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220721055728.718573-18-kaleshsingh@google.com> X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: linux.dev Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Kalesh, Nifty series! Had the chance to take it for a spin :) Few comments below: On Wed, Jul 20, 2022 at 10:57:28PM -0700, Kalesh Singh wrote: > In non-protected nVHE mode, unwinds and dumps the hypervisor backtrace > from EL1. This is possible beacuase the host can directly access the > hypervisor stack pages in non-proteced mode. > > Signed-off-by: Kalesh Singh > --- > > Changes in v5: > - Move code out from nvhe.h header to handle_exit.c, per Marc > - Fix stacktrace symoblization when CONFIG_RAMDOMIZE_BASE is enabled, > per Fuad > - Use regular comments instead of doc comments, per Fuad > > arch/arm64/kvm/handle_exit.c | 65 +++++++++++++++++++++++++++++++----- > 1 file changed, 56 insertions(+), 9 deletions(-) > > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c > index ad568da5c7d7..432b6b26f4ad 100644 > --- a/arch/arm64/kvm/handle_exit.c > +++ b/arch/arm64/kvm/handle_exit.c [...] > @@ -318,6 +319,56 @@ void handle_exit_early(struct kvm_vcpu *vcpu, int exception_index) > kvm_handle_guest_serror(vcpu, kvm_vcpu_get_esr(vcpu)); > } > > +/* > + * kvm_nvhe_print_backtrace_entry - Symbolizes and prints the HYP stack address > + */ > +static void kvm_nvhe_print_backtrace_entry(unsigned long addr, > + unsigned long hyp_offset) > +{ > + unsigned long va_mask = GENMASK_ULL(vabits_actual - 1, 0); > + > + /* Mask tags and convert to kern addr */ > + addr = (addr & va_mask) + hyp_offset; > + kvm_err(" [<%016lx>] %pB\n", addr, (void *)(addr + kaslr_offset())); > +} It is a bit odd to see this get churned from the last patch. Is it possible to introduce the helper earlier on? In fact, the non-protected patch should come first to layer the series better. Also, it seems to me that there isn't much need for the indirection if the pKVM unwinder is made to work around the below function signature: > +/* > + * hyp_dump_backtrace_entry - Dump an entry of the non-protected nVHE HYP stacktrace > + * > + * @arg : the hypervisor offset, used for address translation > + * @where : the program counter corresponding to the stack frame > + */ > +static bool hyp_dump_backtrace_entry(void *arg, unsigned long where) > +{ > + kvm_nvhe_print_backtrace_entry(where, (unsigned long)arg); > + > + return true; > +} > +/* > + * hyp_dump_backtrace - Dump the non-proteced nVHE HYP backtrace. > + * > + * @hyp_offset: hypervisor offset, used for address translation. > + * > + * The host can directly access HYP stack pages in non-protected > + * mode, so the unwinding is done directly from EL1. This removes > + * the need for shared buffers between host and hypervisor for > + * the stacktrace. > + */ > +static void hyp_dump_backtrace(unsigned long hyp_offset) > +{ > + struct kvm_nvhe_stacktrace_info *stacktrace_info; > + struct unwind_state state; > + > + stacktrace_info = this_cpu_ptr_nvhe_sym(kvm_stacktrace_info); > + > + kvm_nvhe_unwind_init(&state, stacktrace_info->fp, stacktrace_info->pc); > + > + kvm_err("Non-protected nVHE HYP call trace:\n"); I don't see the value in discerning non-protected vs. protected in the preamble, as panic() will dump the kernel commandline which presumably would have a `kvm-arm.mode=protected` in the case of pKVM. Not entirely your problem, but we should really use a consistent name for that thing we have living at EL2. Hyp or nVHE (but not both) would be appropriate. > + unwind(&state, hyp_dump_backtrace_entry, (void *)hyp_offset); > + kvm_err("---- End of Non-protected nVHE HYP call trace ----\n"); Maybe: kvm_err("---[ end ${NAME_FOR_EL2} trace ]---"); (more closely matches the pattern of the arm64 stacktrace) -- Thanks, Oliver