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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6A846C433ED for ; Fri, 7 May 2021 14:32:01 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 216AB610D2 for ; Fri, 7 May 2021 14:32:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237648AbhEGOc7 (ORCPT ); Fri, 7 May 2021 10:32:59 -0400 Received: from mail.kernel.org ([198.145.29.99]:51632 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235979AbhEGOc7 (ORCPT ); Fri, 7 May 2021 10:32:59 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 271726101A; Fri, 7 May 2021 14:31:59 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1lf1WG-00BTpD-Pj; Fri, 07 May 2021 15:31:57 +0100 Date: Fri, 07 May 2021 15:31:56 +0100 Message-ID: <877dkapqcj.wl-maz@kernel.org> From: Marc Zyngier To: Ricardo Koller Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, pbonzini@redhat.com, drjones@redhat.com, alexandru.elisei@arm.com, eric.auger@redhat.com Subject: Re: [PATCH v2 4/5] KVM: selftests: Add exception handling support for aarch64 In-Reply-To: References: <20210430232408.2707420-1-ricarkol@google.com> <20210430232408.2707420-5-ricarkol@google.com> <87a6pcumyg.wl-maz@kernel.org> 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: 62.31.163.78 X-SA-Exim-Rcpt-To: ricarkol@google.com, kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, pbonzini@redhat.com, drjones@redhat.com, alexandru.elisei@arm.com, eric.auger@redhat.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: kvm@vger.kernel.org On Mon, 03 May 2021 20:12:21 +0100, Ricardo Koller wrote: > > On Mon, May 03, 2021 at 11:32:39AM +0100, Marc Zyngier wrote: > > On Sat, 01 May 2021 00:24:06 +0100, > > Ricardo Koller wrote: [...] > > > + .if \vector >= 8 > > > + mrs x1, sp_el0 > > > > I'm still a bit perplexed by this. SP_EL0 is never changed, since you > > always run in handler mode. Therefore, saving/restoring it is only > > overhead. If an exception handler wants to introspect it, it is > > already available in the relevant system register. > > > > Or did you have something else in mind for it? > > > > Not really. The reason for saving sp_el0 in there was just for > consistency, so that handlers for both el0 and el1 exceptions could > get the sp at regs->sp. We already have sp_el0 consistency by virtue of having it stored in in a sysreg. > Restoring sp_el0 might be too much. So, what do you think of this > v3: we keep the saving of sp_el0 into regs->sp (to keep things the > same between el0 and el1) and delete the restoring of sp_el0? To me, the whole purpose of saving some some context is to allow the exception handling code to run C code and introspect the interrupted state. But saving things that are not affected by the context change seems a bit pointless. One thing I'd like to see though is to save sp_el1 as it was at the point of the exception (because that is meaningful to get the exception context -- think of an unaligned EL1 stack for example), which means correcting the value that gets saved. So I would suggest to *only* save sp_el1, to always save it (irrespective of the exception coming from EL0 or EL1), and to save a retro-corrected value so that the handler can directly know where the previous stack pointer was. Thanks, M. -- Without deviation from the norm, progress is not possible.