linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Oliver Upton <oliver.upton@linux.dev>
To: Kalesh Singh <kaleshsingh@google.com>
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()
Date: Thu, 21 Jul 2022 21:35:26 +0100	[thread overview]
Message-ID: <Ytm4ji93wyjRI7Jw@google.com> (raw)
In-Reply-To: <20220721055728.718573-18-kaleshsingh@google.com>

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 <kaleshsingh@google.com>
> ---
> 
> 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:

<snip>

> +/*
> + * 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;
> +}

</snip>

> +/*
> + * 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.

<nit>

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.

</nit>

> +	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

  parent reply	other threads:[~2022-07-21 20:36 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-21  5:57 [PATCH v5 00/17] KVM nVHE Hypervisor stack unwinder Kalesh Singh
2022-07-21  5:57 ` [PATCH v5 01/17] arm64: stacktrace: Add shared header for common stack unwinding code Kalesh Singh
2022-07-21  5:57 ` [PATCH v5 02/17] arm64: stacktrace: Factor out on_accessible_stack_common() Kalesh Singh
2022-07-21  5:57 ` [PATCH v5 03/17] arm64: stacktrace: Factor out unwind_next_common() Kalesh Singh
2022-07-21  5:57 ` [PATCH v5 04/17] arm64: stacktrace: Handle frame pointer from different address spaces Kalesh Singh
2022-07-21  9:57   ` Fuad Tabba
2022-07-21  5:57 ` [PATCH v5 05/17] arm64: stacktrace: Factor out common unwind() Kalesh Singh
2022-07-25 14:05   ` Mark Brown
2022-07-21  5:57 ` [PATCH v5 06/17] arm64: stacktrace: Add description of stacktrace/common.h Kalesh Singh
2022-07-21  9:57   ` Fuad Tabba
2022-07-21  5:57 ` [PATCH v5 07/17] KVM: arm64: On stack overflow switch to hyp overflow_stack Kalesh Singh
2022-07-21  5:57 ` [PATCH v5 08/17] KVM: arm64: Add PROTECTED_NVHE_STACKTRACE Kconfig Kalesh Singh
2022-07-21  9:57   ` Fuad Tabba
2022-07-21  5:57 ` [PATCH v5 09/17] KVM: arm64: Allocate shared pKVM hyp stacktrace buffers Kalesh Singh
2022-07-21  9:57   ` Fuad Tabba
2022-07-21  5:57 ` [PATCH v5 10/17] KVM: arm64: Stub implementation of pKVM HYP stack unwinder Kalesh Singh
2022-07-21  9:58   ` Fuad Tabba
2022-07-21  5:57 ` [PATCH v5 11/17] KVM: arm64: Stub implementation of non-protected nVHE " Kalesh Singh
2022-07-21  9:58   ` Fuad Tabba
2022-07-21  5:57 ` [PATCH v5 12/17] KVM: arm64: Save protected-nVHE (pKVM) hyp stacktrace Kalesh Singh
2022-07-21  9:58   ` Fuad Tabba
2022-07-22 15:33   ` Oliver Upton
2022-07-22 17:28     ` Kalesh Singh
2022-07-21  5:57 ` [PATCH v5 13/17] KVM: arm64: Prepare non-protected nVHE hypervisor stacktrace Kalesh Singh
2022-07-21  9:58   ` Fuad Tabba
2022-07-21  5:57 ` [PATCH v5 14/17] KVM: arm64: Implement protected nVHE hyp stack unwinder Kalesh Singh
2022-07-21  9:58   ` Fuad Tabba
2022-07-21  5:57 ` [PATCH v5 15/17] KVM: arm64: Implement non-protected " Kalesh Singh
2022-07-21  9:58   ` Fuad Tabba
2022-07-21  5:57 ` [PATCH v5 16/17] KVM: arm64: Introduce pkvm_dump_backtrace() Kalesh Singh
2022-07-21  9:59   ` Fuad Tabba
2022-07-22 11:16   ` Oliver Upton
2022-07-22 17:25     ` Kalesh Singh
2022-07-21  5:57 ` [PATCH v5 17/17] KVM: arm64: Introduce hyp_dump_backtrace() Kalesh Singh
2022-07-21  9:59   ` Fuad Tabba
2022-07-21 20:35   ` Oliver Upton [this message]
2022-07-22  0:01     ` Kalesh Singh
2022-07-21  9:55 ` [PATCH v5 00/17] KVM nVHE Hypervisor stack unwinder Fuad Tabba
2022-07-21 16:06   ` Kalesh Singh
2022-07-22 10:48 ` Oliver Upton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Ytm4ji93wyjRI7Jw@google.com \
    --to=oliver.upton@linux.dev \
    --cc=alexandru.elisei@arm.com \
    --cc=andreyknvl@gmail.com \
    --cc=android-mm@google.com \
    --cc=ardb@kernel.org \
    --cc=ast@kernel.org \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=drjones@redhat.com \
    --cc=elver@google.com \
    --cc=james.morse@arm.com \
    --cc=kaleshsingh@google.com \
    --cc=keirf@google.com \
    --cc=kernel-team@android.com \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=madvenka@linux.microsoft.com \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=qperret@google.com \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --cc=vincenzo.frascino@arm.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=will@kernel.org \
    --cc=yuzenghui@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).