From patchwork Thu Oct 31 15:09:06 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julien Grall X-Patchwork-Id: 11221419 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 36D9217E6 for ; Thu, 31 Oct 2019 15:11:12 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1C4212087E for ; Thu, 31 Oct 2019 15:11:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1C4212087E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iQC4y-0006SF-6J; Thu, 31 Oct 2019 15:09:40 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iQC4x-0006S8-Bg for xen-devel@lists.xenproject.org; Thu, 31 Oct 2019 15:09:39 +0000 X-Inumbo-ID: 7460388e-fbf0-11e9-a531-bc764e2007e4 Received: from foss.arm.com (unknown [217.140.110.172]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 7460388e-fbf0-11e9-a531-bc764e2007e4; Thu, 31 Oct 2019 15:09:37 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 22F8255D; Thu, 31 Oct 2019 08:09:37 -0700 (PDT) Received: from e108454-lin.cambridge.arm.com (unknown [10.1.196.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3B1C63F71E; Thu, 31 Oct 2019 08:09:36 -0700 (PDT) From: Julien Grall To: xen-devel@lists.xenproject.org Date: Thu, 31 Oct 2019 15:09:06 +0000 Message-Id: <20191031150922.22938-4-julien.grall@arm.com> X-Mailer: git-send-email 2.11.0 In-Reply-To: <20191031150922.22938-1-julien.grall@arm.com> References: <20191031150922.22938-1-julien.grall@arm.com> Subject: [Xen-devel] [PATCH for-4.13 v4 03/19] xen/arm: traps: Rework __do_serror() documentation X-BeenThere: xen-devel@lists.xenproject.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Cc: jgross@suse.com, Volodymyr Babchuk , Julien Grall , Stefano Stabellini , Julien Grall MIME-Version: 1.0 Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The documentation on top of __do_serror() is trying to describe all the possibilities to receive an SErrors. The description of type#2 is quite misleading because receiving an SError in EL2 after unmasking SError interrupt ({PSTATE, CPSR}.A) does not necessarily imply the SError were generated by the guest. You also need to be in a special window (see abort_guest_exist_{guest, end}). However, for the context of the function it does not matter how we categorize the interrupts. What matter is to know whether this is a guest-generated SError. All the documentation of __do_serror() is now reworked to avoid misleading information. Take the opportunity to simplify the code after the forward option has been dropped. Signed-off-by: Julien Grall Acked-by: Stefano Stabellini --- Changes in v3: - Fix typo - Add Stefano's acked-by Changes in v2: - Patch added --- xen/arch/arm/traps.c | 36 +++++++++++++----------------------- 1 file changed, 13 insertions(+), 23 deletions(-) diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c index 6ed9e66710..3262052f47 100644 --- a/xen/arch/arm/traps.c +++ b/xen/arch/arm/traps.c @@ -660,41 +660,31 @@ static void inject_vabt_exception(struct cpu_user_regs *regs) } /* - * SError exception handler. We only handle the following 3 types of SErrors: - * 1) Guest-generated SError and had been delivered in EL1 and then - * been forwarded to EL2. - * 2) Guest-generated SError but hadn't been delivered in EL1 before - * trapping to EL2. This SError would be caught in EL2 as soon as - * we just unmasked the PSTATE.A bit. - * 3) Hypervisor generated native SError, that would be a bug. + * SError exception handler. * * A true parameter "guest" means that the SError is type#1 or type#2. * + * @guest indicates whether this is a SError generated by the guest. + * + * If true, the SError was generated by the guest, so it is safe to continue + * and forward to the guest (if requested). + * + * If false, the SError was likely generated by the hypervisor. As we cannot + * distinguish between precise and imprecise SErrors, it is not safe to + * continue. + * * Note that Arm32 asynchronous external abort generated by the * hypervisor will be handled in do_trap_data_abort(). */ static void __do_trap_serror(struct cpu_user_regs *regs, bool guest) { /* - * Only "DIVERSE" option needs to distinguish the guest-generated SErrors - * from hypervisor SErrors. + * When using "DIVERSE", the SErrors generated by the guest will be + * forwarded to the currently running vCPU. */ - if ( serrors_op == SERRORS_DIVERSE ) - { - /* Forward the type#1 and type#2 SErrors to guests. */ - if ( guest ) + if ( serrors_op == SERRORS_DIVERSE && guest ) return inject_vabt_exception(regs); - /* Type#3 SErrors will panic the whole system */ - goto crash_system; - } - -crash_system: - /* - * Two possibilities to crash the whole system: - * 1) "DIVERSE" option with Hypervisor generated SErrors. - * 2) "PANIC" option with all SErrors. - */ do_unexpected_trap("SError", regs); }