Linux KVM/arm64 development list
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Kalesh Singh <kaleshsingh@google.com>
Cc: "moderated list:ARM64 PORT \(AARCH64 ARCHITECTURE\)"
	<linux-arm-kernel@lists.infradead.org>,
	kvmarm <kvmarm@lists.cs.columbia.edu>,
	"Cc: Android Kernel" <kernel-team@android.com>,
	Andrew Walbran <qwandor@google.com>,
	Will Deacon <will@kernel.org>,
	Peter Collingbourne <pcc@google.com>,
	Marc Zyngier <maz@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Stephen Boyd <swboyd@chromium.org>,
	"Madhavan T. Venkataraman" <madvenka@linux.microsoft.com>,
	Mark Brown <broonie@kernel.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Suren Baghdasaryan <surenb@google.com>
Subject: Re: [PATCH v6 7/8] KVM: arm64: Unwind and dump nVHE HYP stacktrace
Date: Thu, 21 Apr 2022 10:00:36 +0100	[thread overview]
Message-ID: <YmEdNME45PJr5w+Y@FVFF77S0Q05N> (raw)
In-Reply-To: <CAC_TJveJYFkHPQLYdL8SCEAwMPgwpF_-ctMqKJ9w=eDa_M0u5w@mail.gmail.com>

On Tue, Apr 19, 2022 at 10:37:56AM -0700, Kalesh Singh wrote:
> On Wed, Apr 13, 2022 at 6:59 AM Mark Rutland <mark.rutland@arm.com> wrote:
> > I'm fine with the concept of splitting the unwind and logging steps; this is
> > akin to doing:
> >
> >         stack_trace_save_tsk(...);
> >         ...
> >         stack_trace_print(...);
> >
> > ... and I'm fine with having a stack_trace_save_hyp(...) variant.
> >
> > However, I would like to ensure that we're reusing logic rather than
> > duplicating it wholesale.
> 
> Agreed. Although some reimplementation may be unavoidable, as we can't
> safely link against kernel code from the protected KVM hypervisor.

Sure; I just mean that we have one implementation, even if that gets recompiled
in separate objects for different contexts.

> Perhaps we can move some of the common logic to a shared header that
> can be included in both places (host, hyp), WDYT?

My rough thinking was that we'd build the same stacktrace.c file (reworked from
the current one) as stracktrace.o and stacktrace.nvhe.o, but moving things
around into headers is also an option. Either way will need some
experimentation.

Thanks,
Mark.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

  reply	other threads:[~2022-04-21  9:00 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-14 20:01 [PATCH v6 0/8] KVM: arm64: Hypervisor stack enhancements Kalesh Singh
2022-03-14 20:01 ` [PATCH v6 1/8] KVM: arm64: Introduce hyp_alloc_private_va_range() Kalesh Singh
2022-03-29  8:50   ` Fuad Tabba
2022-03-29 15:37     ` Kalesh Singh
2022-03-14 20:01 ` [PATCH v6 2/8] KVM: arm64: Introduce pkvm_alloc_private_va_range() Kalesh Singh
2022-03-29  8:50   ` Fuad Tabba
2022-03-14 20:01 ` [PATCH v6 3/8] KVM: arm64: Add guard pages for KVM nVHE hypervisor stack Kalesh Singh
2022-03-29  8:50   ` Fuad Tabba
2022-03-14 20:01 ` [PATCH v6 4/8] KVM: arm64: Add guard pages for pKVM (protected nVHE) " Kalesh Singh
2022-03-29  8:51   ` Fuad Tabba
2022-03-14 20:01 ` [PATCH v6 5/8] KVM: arm64: Detect and handle hypervisor stack overflows Kalesh Singh
2022-03-29  8:51   ` Fuad Tabba
2022-03-14 20:01 ` [PATCH v6 6/8] KVM: arm64: Add hypervisor overflow stack Kalesh Singh
2022-03-29  8:51   ` Fuad Tabba
2022-03-14 20:01 ` [PATCH v6 7/8] KVM: arm64: Unwind and dump nVHE HYP stacktrace Kalesh Singh
2022-03-29  8:51   ` Fuad Tabba
2022-03-31 19:22     ` Kalesh Singh
2022-04-13 13:58       ` Mark Rutland
2022-04-19 17:37         ` Kalesh Singh
2022-04-21  9:00           ` Mark Rutland [this message]
2022-03-14 20:01 ` [PATCH v6 8/8] KVM: arm64: Symbolize the nVHE HYP backtrace Kalesh Singh
2022-03-29  8:51   ` Fuad Tabba
2022-03-28 16:55 ` [PATCH v6 0/8] KVM: arm64: Hypervisor stack enhancements Kalesh Singh

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=YmEdNME45PJr5w+Y@FVFF77S0Q05N \
    --to=mark.rutland@arm.com \
    --cc=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=kaleshsingh@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=maz@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=pcc@google.com \
    --cc=qwandor@google.com \
    --cc=surenb@google.com \
    --cc=swboyd@chromium.org \
    --cc=will@kernel.org \
    /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