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 E243BC43334 for ; Mon, 18 Jul 2022 09:36:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 4BB594D45E; Mon, 18 Jul 2022 05:36:17 -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=@kernel.org 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 WDAAhLqLrUpv; Mon, 18 Jul 2022 05:36:16 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 379CE4D45A; Mon, 18 Jul 2022 05:36:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id ECE3A4D457 for ; Mon, 18 Jul 2022 05:36:14 -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 jswpPamqT8rn for ; Mon, 18 Jul 2022 05:36:13 -0400 (EDT) Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id BAF664D43E for ; Mon, 18 Jul 2022 05:36:13 -0400 (EDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 0DC2B614EC; Mon, 18 Jul 2022 09:36:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 64A5CC341C8; Mon, 18 Jul 2022 09:36:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658136970; bh=c6Vl+AMZNcoDWWJaxFMtmHx1sXOLMMx/JcQWNmVAL2k=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=c9GrlWhthHbKfRrtPCKznNgcPZqHC/JfxON1RI4JoBfudVH4+XXicSbdeQ2SUfPU4 3ATmNF7sQuzLW7HfrV0wEulAVRqA0x9bua4OsKkEGkJoAQ38r0yfw4i3ESu2LBBbHr 0e7OPySSHdzrbvy1pQHALj+5C7NqEe4xWU/nROWXzkt0fkeIYmmBZBw/HUdTiQR1nw +25+0/ALVE6Ayim2mXTlUUE2qIPi8Wz7xaKg3a+AjCD433DNxpq7s1fsilPqUox9KB 9BVzWznbmIYfcyGOY9updJKcPWoLJqpVJhhP1FwQIzizMxb5jU65f9sWC9uCHZ/44V +nSOQWjjQYpgA== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oDNAd-008A3w-Vi; Mon, 18 Jul 2022 10:36:08 +0100 Date: Mon, 18 Jul 2022 10:36:07 +0100 Message-ID: <87tu7ezrso.wl-maz@kernel.org> From: Marc Zyngier To: Kalesh Singh Subject: Re: [PATCH v4 12/18] KVM: arm64: Save protected-nVHE (pKVM) hyp stacktrace In-Reply-To: <20220715061027.1612149-13-kaleshsingh@google.com> References: <20220715061027.1612149-1-kaleshsingh@google.com> <20220715061027.1612149-13-kaleshsingh@google.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: kaleshsingh@google.com, mark.rutland@arm.com, broonie@kernel.org, madvenka@linux.microsoft.com, will@kernel.org, qperret@google.com, tabba@google.com, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, catalin.marinas@arm.com, andreyknvl@gmail.com, russell.king@oracle.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, oupton@google.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, linux-kernel@vger.kernel.org, android-mm@google.com, kernel-team@android.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Cc: wangkefeng.wang@huawei.com, elver@google.com, catalin.marinas@arm.com, ast@kernel.org, vincenzo.frascino@arm.com, will@kernel.org, android-mm@google.com, kvmarm@lists.cs.columbia.edu, madvenka@linux.microsoft.com, linux-arm-kernel@lists.infradead.org, andreyknvl@gmail.com, kernel-team@android.com, drjones@redhat.com, broonie@kernel.org, russell.king@oracle.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 On Fri, 15 Jul 2022 07:10:21 +0100, Kalesh Singh wrote: > > In protected nVHE mode, the host cannot access private owned hypervisor > memory. Also the hypervisor aims to remains simple to reduce the attack > surface and does not provide any printk support. > > For the above reasons, the approach taken to provide hypervisor stacktraces > in protected mode is: > 1) Unwind and save the hyp stack addresses in EL2 to a shared buffer > with the host (done in this patch). > 2) Delegate the dumping and symbolization of the addresses to the > host in EL1 (later patch in the series). > > Signed-off-by: Kalesh Singh > --- > arch/arm64/include/asm/stacktrace/nvhe.h | 18 ++++++ > arch/arm64/kvm/hyp/nvhe/stacktrace.c | 70 ++++++++++++++++++++++++ > 2 files changed, 88 insertions(+) > > diff --git a/arch/arm64/include/asm/stacktrace/nvhe.h b/arch/arm64/include/asm/stacktrace/nvhe.h > index 36cf7858ddd8..456a6ae08433 100644 > --- a/arch/arm64/include/asm/stacktrace/nvhe.h > +++ b/arch/arm64/include/asm/stacktrace/nvhe.h > @@ -21,6 +21,22 @@ > > #include > > +/** > + * kvm_nvhe_unwind_init - Start an unwind from the given nVHE HYP fp and pc > + * > + * @fp : frame pointer at which to start the unwinding. > + * @pc : program counter at which to start the unwinding. > + */ > +static __always_inline void kvm_nvhe_unwind_init(struct unwind_state *state, > + unsigned long fp, > + unsigned long pc) > +{ > + unwind_init_common(state, NULL); Huh. Be careful here. This function is only 'inline', which means it may not be really inlined. We've had tons of similar issues like this in the past, and although this will not break at runtime anymore, it will definitely stop the kernel from linking. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm