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 63FFAC433EF for ; Mon, 18 Jul 2022 07:13:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C7F764D291; Mon, 18 Jul 2022 03:13:21 -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 jfX8egewI1l0; Mon, 18 Jul 2022 03:13:20 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 6012A4D2A9; Mon, 18 Jul 2022 03:13:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 7E4024D2A4 for ; Mon, 18 Jul 2022 03:13:19 -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 yyQEh9NvtejL for ; Mon, 18 Jul 2022 03:13:18 -0400 (EDT) Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id E6F004D291 for ; Mon, 18 Jul 2022 03:13:17 -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 sin.source.kernel.org (Postfix) with ESMTPS id AABCACE1283; Mon, 18 Jul 2022 07:13:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CBAF3C341C0; Mon, 18 Jul 2022 07:13:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658128392; bh=51swZxaHJh3GKTY5TD3dhPc0ycstZoPXVjupMS9JkwQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XXjAueojpHAo+0wnGZa7OPm63c4moRcpozBTtgkbHmnr3e/NLNI3XjD2dma7lRViM ERotw0AL0sBjZokWNZT6AETiiVnRXuxHendgkysRZz5QugwCQtaKbyhVeNXBX618Eg iQmyAgu45qZk5MVMpNDowMS5DconlmISNh0bIIMAL6FMmLJL2J504QunH0ftuSAsTo iz6iR+XuzONiCKAnScyjy815y7n/27b3bU2NokneKx5SciSrUXj0z5IVEIuJs3Judg hIwN8+Eb12/m/N5oTvgqHYXK38v1nxmFMzs7FofdfCmbQZKxsQ98CVFS5BuE+/a/VI j+9VtH1ZDofJA== Received: from 82-132-227-210.dab.02.net ([82.132.227.210] helo=wait-a-minute.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 1oDKwI-0088Nz-IW; Mon, 18 Jul 2022 08:13:10 +0100 Date: Mon, 18 Jul 2022 08:13:00 +0100 Message-ID: <87bktm51xf.wl-maz@kernel.org> From: Marc Zyngier To: Kalesh Singh Subject: Re: [PATCH v4 09/18] KVM: arm64: Allocate shared pKVM hyp stacktrace buffers In-Reply-To: <20220715061027.1612149-10-kaleshsingh@google.com> References: <20220715061027.1612149-1-kaleshsingh@google.com> <20220715061027.1612149-10-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: 82.132.227.210 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, 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, 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, catalin.marinas@arm.com, ast@kernel.org, vincenzo.frascino@arm.com, will@kernel.org, kvmarm@lists.cs.columbia.edu, madvenka@linux.microsoft.com, andreyknvl@gmail.com, kernel-team@android.com, elver@google.com, broonie@kernel.org, linux-arm-kernel@lists.infradead.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:18 +0100, Kalesh Singh wrote: > > In protected nVHE mode the host cannot directly access > hypervisor memory, so we will dump the hypervisor stacktrace > to a shared buffer with the host. > > The minimum size do the buffer required, assuming the min frame s/do/for/ ? > size of [x29, x30] (2 * sizeof(long)), is half the combined size of > the hypervisor and overflow stacks plus an additional entry to > delimit the end of the stacktrace. Let me see if I understand this: the maximum stack size is the combination of the HYP and overflow stacks, and the smallest possible stack frame is 128bit (only FP+LR). The buffer thus needs to provide one 64bit entry per stack frame that fits in the combined stack, plus one entry as an end marker. So the resulting size is half of the combined stack size, plus a single 64bit word. Is this correct? > > The stacktrace buffers are used later in the seried to dump the > nVHE hypervisor stacktrace when using protected-mode. > > Signed-off-by: Kalesh Singh > --- > arch/arm64/include/asm/memory.h | 7 +++++++ > arch/arm64/kvm/hyp/nvhe/stacktrace.c | 4 ++++ > 2 files changed, 11 insertions(+) > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h > index 0af70d9abede..28a4893d4b84 100644 > --- a/arch/arm64/include/asm/memory.h > +++ b/arch/arm64/include/asm/memory.h > @@ -113,6 +113,13 @@ > > #define OVERFLOW_STACK_SIZE SZ_4K > > +/* > + * With the minimum frame size of [x29, x30], exactly half the combined > + * sizes of the hyp and overflow stacks is needed to save the unwinded > + * stacktrace; plus an additional entry to delimit the end. > + */ > +#define NVHE_STACKTRACE_SIZE ((OVERFLOW_STACK_SIZE + PAGE_SIZE) / 2 + sizeof(long)) > + > /* > * Alignment of kernel segments (e.g. .text, .data). > * > diff --git a/arch/arm64/kvm/hyp/nvhe/stacktrace.c b/arch/arm64/kvm/hyp/nvhe/stacktrace.c > index a3d5b34e1249..69e65b457f1c 100644 > --- a/arch/arm64/kvm/hyp/nvhe/stacktrace.c > +++ b/arch/arm64/kvm/hyp/nvhe/stacktrace.c > @@ -9,3 +9,7 @@ > > DEFINE_PER_CPU(unsigned long [OVERFLOW_STACK_SIZE/sizeof(long)], overflow_stack) > __aligned(16); > + > +#ifdef CONFIG_PROTECTED_NVHE_STACKTRACE > +DEFINE_PER_CPU(unsigned long [NVHE_STACKTRACE_SIZE/sizeof(long)], pkvm_stacktrace); > +#endif /* CONFIG_PROTECTED_NVHE_STACKTRACE */ OK, so the allocation exists even if KVM is not running in protected mode. I guess this is OK for now, but definitely reinforces my request that this is only there when compiled for debug mode. 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 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 8B6B3C433EF for ; Mon, 18 Jul 2022 07:14:27 +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:MIME-Version:References:In-Reply-To: Subject:Cc:To:From:Message-ID:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=jNmuojqnyNWrT/H9D2OSHElMuEGBLufDvqT4ypa9gUU=; b=pezUNd+D3Ucjub Sp0JuOYQLU3e8m2ZY+VWQDTStMm9jLlIN/v0rxiEnF0gKNpRVYYJHoI3g0Zwf82IiBbpGNDs8ldAj nSL9wvVWPqi6OAZ7gCkbrK/b6kbZzaypM5ufF6+wrrDLJY//4BDviM3K/v4cQbDGxtlN0oiwOPku2 Up1lwwGtHRcGbQ0d7MkDdkOZz9QepMOBi8UpA3LLTlFvIKHgpitDVxwB24RAc5hfZgc0TXQua2FMY 4972+HamfNmuq/6uAvJHfgTTB5WDu2BJwvong3ogD2AswCAKawF09l8R6pAwto4xrM1siw/qzjYOf Qqq9xd8CoJ7tbuGwAiUw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oDKwT-00BPY8-Dp; Mon, 18 Jul 2022 07:13:21 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oDKwQ-00BPW9-1J for linux-arm-kernel@lists.infradead.org; Mon, 18 Jul 2022 07:13:19 +0000 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 sin.source.kernel.org (Postfix) with ESMTPS id AABCACE1283; Mon, 18 Jul 2022 07:13:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CBAF3C341C0; Mon, 18 Jul 2022 07:13:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658128392; bh=51swZxaHJh3GKTY5TD3dhPc0ycstZoPXVjupMS9JkwQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XXjAueojpHAo+0wnGZa7OPm63c4moRcpozBTtgkbHmnr3e/NLNI3XjD2dma7lRViM ERotw0AL0sBjZokWNZT6AETiiVnRXuxHendgkysRZz5QugwCQtaKbyhVeNXBX618Eg iQmyAgu45qZk5MVMpNDowMS5DconlmISNh0bIIMAL6FMmLJL2J504QunH0ftuSAsTo iz6iR+XuzONiCKAnScyjy815y7n/27b3bU2NokneKx5SciSrUXj0z5IVEIuJs3Judg hIwN8+Eb12/m/N5oTvgqHYXK38v1nxmFMzs7FofdfCmbQZKxsQ98CVFS5BuE+/a/VI j+9VtH1ZDofJA== Received: from 82-132-227-210.dab.02.net ([82.132.227.210] helo=wait-a-minute.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 1oDKwI-0088Nz-IW; Mon, 18 Jul 2022 08:13:10 +0100 Date: Mon, 18 Jul 2022 08:13:00 +0100 Message-ID: <87bktm51xf.wl-maz@kernel.org> From: Marc Zyngier To: Kalesh Singh Cc: 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, 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, kernel-team@android.com Subject: Re: [PATCH v4 09/18] KVM: arm64: Allocate shared pKVM hyp stacktrace buffers In-Reply-To: <20220715061027.1612149-10-kaleshsingh@google.com> References: <20220715061027.1612149-1-kaleshsingh@google.com> <20220715061027.1612149-10-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: 82.132.227.210 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, 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, 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220718_001318_551395_60884BD3 X-CRM114-Status: GOOD ( 28.03 ) 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 On Fri, 15 Jul 2022 07:10:18 +0100, Kalesh Singh wrote: > > In protected nVHE mode the host cannot directly access > hypervisor memory, so we will dump the hypervisor stacktrace > to a shared buffer with the host. > > The minimum size do the buffer required, assuming the min frame s/do/for/ ? > size of [x29, x30] (2 * sizeof(long)), is half the combined size of > the hypervisor and overflow stacks plus an additional entry to > delimit the end of the stacktrace. Let me see if I understand this: the maximum stack size is the combination of the HYP and overflow stacks, and the smallest possible stack frame is 128bit (only FP+LR). The buffer thus needs to provide one 64bit entry per stack frame that fits in the combined stack, plus one entry as an end marker. So the resulting size is half of the combined stack size, plus a single 64bit word. Is this correct? > > The stacktrace buffers are used later in the seried to dump the > nVHE hypervisor stacktrace when using protected-mode. > > Signed-off-by: Kalesh Singh > --- > arch/arm64/include/asm/memory.h | 7 +++++++ > arch/arm64/kvm/hyp/nvhe/stacktrace.c | 4 ++++ > 2 files changed, 11 insertions(+) > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h > index 0af70d9abede..28a4893d4b84 100644 > --- a/arch/arm64/include/asm/memory.h > +++ b/arch/arm64/include/asm/memory.h > @@ -113,6 +113,13 @@ > > #define OVERFLOW_STACK_SIZE SZ_4K > > +/* > + * With the minimum frame size of [x29, x30], exactly half the combined > + * sizes of the hyp and overflow stacks is needed to save the unwinded > + * stacktrace; plus an additional entry to delimit the end. > + */ > +#define NVHE_STACKTRACE_SIZE ((OVERFLOW_STACK_SIZE + PAGE_SIZE) / 2 + sizeof(long)) > + > /* > * Alignment of kernel segments (e.g. .text, .data). > * > diff --git a/arch/arm64/kvm/hyp/nvhe/stacktrace.c b/arch/arm64/kvm/hyp/nvhe/stacktrace.c > index a3d5b34e1249..69e65b457f1c 100644 > --- a/arch/arm64/kvm/hyp/nvhe/stacktrace.c > +++ b/arch/arm64/kvm/hyp/nvhe/stacktrace.c > @@ -9,3 +9,7 @@ > > DEFINE_PER_CPU(unsigned long [OVERFLOW_STACK_SIZE/sizeof(long)], overflow_stack) > __aligned(16); > + > +#ifdef CONFIG_PROTECTED_NVHE_STACKTRACE > +DEFINE_PER_CPU(unsigned long [NVHE_STACKTRACE_SIZE/sizeof(long)], pkvm_stacktrace); > +#endif /* CONFIG_PROTECTED_NVHE_STACKTRACE */ OK, so the allocation exists even if KVM is not running in protected mode. I guess this is OK for now, but definitely reinforces my request that this is only there when compiled for debug mode. Thanks, M. -- Without deviation from the norm, progress is not possible. _______________________________________________ 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 C8905C433EF for ; Mon, 18 Jul 2022 07:13:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233764AbiGRHNQ (ORCPT ); Mon, 18 Jul 2022 03:13:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45958 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231689AbiGRHNO (ORCPT ); Mon, 18 Jul 2022 03:13:14 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E7D2517A86 for ; Mon, 18 Jul 2022 00:13:13 -0700 (PDT) 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 845A461319 for ; Mon, 18 Jul 2022 07:13:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CBAF3C341C0; Mon, 18 Jul 2022 07:13:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1658128392; bh=51swZxaHJh3GKTY5TD3dhPc0ycstZoPXVjupMS9JkwQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=XXjAueojpHAo+0wnGZa7OPm63c4moRcpozBTtgkbHmnr3e/NLNI3XjD2dma7lRViM ERotw0AL0sBjZokWNZT6AETiiVnRXuxHendgkysRZz5QugwCQtaKbyhVeNXBX618Eg iQmyAgu45qZk5MVMpNDowMS5DconlmISNh0bIIMAL6FMmLJL2J504QunH0ftuSAsTo iz6iR+XuzONiCKAnScyjy815y7n/27b3bU2NokneKx5SciSrUXj0z5IVEIuJs3Judg hIwN8+Eb12/m/N5oTvgqHYXK38v1nxmFMzs7FofdfCmbQZKxsQ98CVFS5BuE+/a/VI j+9VtH1ZDofJA== Received: from 82-132-227-210.dab.02.net ([82.132.227.210] helo=wait-a-minute.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 1oDKwI-0088Nz-IW; Mon, 18 Jul 2022 08:13:10 +0100 Date: Mon, 18 Jul 2022 08:13:00 +0100 Message-ID: <87bktm51xf.wl-maz@kernel.org> From: Marc Zyngier To: Kalesh Singh Cc: 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, 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, kernel-team@android.com Subject: Re: [PATCH v4 09/18] KVM: arm64: Allocate shared pKVM hyp stacktrace buffers In-Reply-To: <20220715061027.1612149-10-kaleshsingh@google.com> References: <20220715061027.1612149-1-kaleshsingh@google.com> <20220715061027.1612149-10-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") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 82.132.227.210 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, 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, 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 15 Jul 2022 07:10:18 +0100, Kalesh Singh wrote: > > In protected nVHE mode the host cannot directly access > hypervisor memory, so we will dump the hypervisor stacktrace > to a shared buffer with the host. > > The minimum size do the buffer required, assuming the min frame s/do/for/ ? > size of [x29, x30] (2 * sizeof(long)), is half the combined size of > the hypervisor and overflow stacks plus an additional entry to > delimit the end of the stacktrace. Let me see if I understand this: the maximum stack size is the combination of the HYP and overflow stacks, and the smallest possible stack frame is 128bit (only FP+LR). The buffer thus needs to provide one 64bit entry per stack frame that fits in the combined stack, plus one entry as an end marker. So the resulting size is half of the combined stack size, plus a single 64bit word. Is this correct? > > The stacktrace buffers are used later in the seried to dump the > nVHE hypervisor stacktrace when using protected-mode. > > Signed-off-by: Kalesh Singh > --- > arch/arm64/include/asm/memory.h | 7 +++++++ > arch/arm64/kvm/hyp/nvhe/stacktrace.c | 4 ++++ > 2 files changed, 11 insertions(+) > > diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h > index 0af70d9abede..28a4893d4b84 100644 > --- a/arch/arm64/include/asm/memory.h > +++ b/arch/arm64/include/asm/memory.h > @@ -113,6 +113,13 @@ > > #define OVERFLOW_STACK_SIZE SZ_4K > > +/* > + * With the minimum frame size of [x29, x30], exactly half the combined > + * sizes of the hyp and overflow stacks is needed to save the unwinded > + * stacktrace; plus an additional entry to delimit the end. > + */ > +#define NVHE_STACKTRACE_SIZE ((OVERFLOW_STACK_SIZE + PAGE_SIZE) / 2 + sizeof(long)) > + > /* > * Alignment of kernel segments (e.g. .text, .data). > * > diff --git a/arch/arm64/kvm/hyp/nvhe/stacktrace.c b/arch/arm64/kvm/hyp/nvhe/stacktrace.c > index a3d5b34e1249..69e65b457f1c 100644 > --- a/arch/arm64/kvm/hyp/nvhe/stacktrace.c > +++ b/arch/arm64/kvm/hyp/nvhe/stacktrace.c > @@ -9,3 +9,7 @@ > > DEFINE_PER_CPU(unsigned long [OVERFLOW_STACK_SIZE/sizeof(long)], overflow_stack) > __aligned(16); > + > +#ifdef CONFIG_PROTECTED_NVHE_STACKTRACE > +DEFINE_PER_CPU(unsigned long [NVHE_STACKTRACE_SIZE/sizeof(long)], pkvm_stacktrace); > +#endif /* CONFIG_PROTECTED_NVHE_STACKTRACE */ OK, so the allocation exists even if KVM is not running in protected mode. I guess this is OK for now, but definitely reinforces my request that this is only there when compiled for debug mode. Thanks, M. -- Without deviation from the norm, progress is not possible.