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 657A0C25B76 for ; Wed, 5 Jun 2024 16:03:22 +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=GZEdhWlglMEG2DwlYfzFGWzmemC22CbwNM7mjhaBNGM=; b=hUD7iMOTJvE7UC OO0JcUSLnm7zV86SbF1iM5heNggAVyJXTDqwBhTowaClTMIVTL/OxCHKL+/hXxzWc7nyBeImQyaKy Q4ViK8uK55apn7voVL95AQ5TPIatR73VDzna7NaCKUZUCroTqyOV1RhnpMAHuQ4O+79xdQKZ1TPIf mgiGopbOAJVMuwocTRav6YfketI69vh+qPr4FZkpBDc0L2UIczQDEU7gV5KpfiKY6myPPVEafko+O thS0M4B+cAIJL1Ivlr1vwmc8BnI2pm5cg2o/svc4M5IKkNQWO6xrMgP7XTZv4xdRHhV6Vhi9JGEzs jJxQ3NuohR48M0OiveZw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sEt6Q-00000006la7-0M97; Wed, 05 Jun 2024 16:03:06 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sEt6M-00000006lZH-1dhL for linux-arm-kernel@lists.infradead.org; Wed, 05 Jun 2024 16:03:04 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id A106E619A2; Wed, 5 Jun 2024 16:03:01 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E44C9C3277B; Wed, 5 Jun 2024 16:02:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717603381; bh=5PGKLYGBYfyqSWcJBCPurIVx/TWoCyZIYimjVoqwxgg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=O7MO2dbJ2mQOIeJzqM5LSuqmK2Zhqjy8Po9lWoXno6+uKhGuxeuVj43hSOhOctoNn cn94s1lbEJyaaA92NBO4qgzHRpeM9QpJiRHI+1C4QDPVNvDb1L05cMpMxqS1YBl1Rv ve7cWPHQo8VzdQHSxr1a9Q3zjlh8ttnwGbjeIDfFkyp9Jfv+VnE8X9Jk5uVCWEex7q nvefAybgSjPxgt4gHZ0lNBF99zv3mr2q1y4hrEBqXBsQU5lOPuaTMcrUG5zMTm6Soy 2PBgRKXrAsYyBF7c5ONohrMcK3Pfsg0F4sxRiR4+PBGAR08xt0SxwBrT2f4KjcwFHS OZ+aK+FTmPALg== Date: Wed, 5 Jun 2024 17:02:56 +0100 From: Will Deacon To: =?iso-8859-1?Q?Pierre-Cl=E9ment?= Tosi Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, Marc Zyngier , Oliver Upton , Suzuki K Poulose , Vincent Donnefort Subject: Re: [PATCH v4 03/13] KVM: arm64: nVHE: Simplify __guest_exit_panic path Message-ID: <20240605160256.GA22199@willie-the-truck> References: <20240529121251.1993135-1-ptosi@google.com> <20240529121251.1993135-4-ptosi@google.com> <20240603143030.GD19151@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240605_090302_739262_8B8775E6 X-CRM114-Status: GOOD ( 34.30 ) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jun 04, 2024 at 04:48:02PM +0100, Pierre-Cl=E9ment Tosi wrote: > On Mon, Jun 03, 2024 at 03:30:30PM +0100, Will Deacon wrote: > > On Wed, May 29, 2024 at 01:12:09PM +0100, Pierre-Cl=E9ment Tosi wrote: > > > diff --git a/arch/arm64/kvm/hyp/nvhe/host.S b/arch/arm64/kvm/hyp/nvhe= /host.S > > > index 135cfb294ee5..71fb311b4c0e 100644 > > > --- a/arch/arm64/kvm/hyp/nvhe/host.S > > > +++ b/arch/arm64/kvm/hyp/nvhe/host.S > > > @@ -197,18 +197,13 @@ SYM_FUNC_END(__host_hvc) > > > sub x0, sp, x0 // x0'' =3D sp' - x0' =3D (sp + x0) - sp =3D x0 > > > sub sp, sp, x0 // sp'' =3D sp' - x0 =3D (sp + x0) - x0 =3D sp > > > = > > > - /* If a guest is loaded, panic out of it. */ > > > - stp x0, x1, [sp, #-16]! > > > - get_loaded_vcpu x0, x1 > > > - cbnz x0, __guest_exit_panic > > > - add sp, sp, #16 > > = > > I think this is actually dead code and we should just remove it. AFAICT, > > invalid_host_el2_vect is only used for the host vectors and the loaded > > vCPU will always be NULL, so this is pointless. set_loaded_vcpu() is > > only called by the low-level guest entry/exit code and with the guest > > EL2 vectors installed. > = > This is correct. > = > > > - > > > /* > > > * The panic may not be clean if the exception is taken before the = host > > > * context has been saved by __host_exit or after the hyp context h= as > > > * been partially clobbered by __host_enter. > > > */ > > > - b hyp_panic > > > + stp x0, x1, [sp, #-16]! > > > + b __guest_exit_panic > > = > > In which case, this should just be: > > = > > add sp, sp, #16 > > b hyp_panic > > = > > Did I miss something? > = > Jumping to hyp_panic directly makes sense. > = > However, this patch keeps jumping to __guest_exit_panic() to prepare for = the > kCFI changes as having a single point where all handlers (from various ve= ctors) > panicking from assembly end up before branching to C turns out to be very > convenient for hooking in the kCFI handler (e.g. when saving the registe= rs, to > be parsed from C). I also didn't want to modify the same code twice in the > series and found it easier to limit the scope of this commit to a minimum= by > following the existing code and keeping the same branch target. > = > With this in mind, please confirm if you still prefer this fix to jump to > hyp_panic directly (knowing the branch will be modified again in the seri= es). I think having a patch which removes the dead code and has the unconditional branch to hyp_panic is the best thing here. It might change later on in the series, but it's a sensible patch on its own and, with assembly, I think having small incremental changes is the best option. > Also, I don't get why the 'add sp, sp, #16' is needed; what is it undoing? Oh, sorry, I missed that you'd dropped the stp earlier on. So the SP doesn't need any adjusting and we can just branch to hyp_panic after the overflow check. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel