From patchwork Thu Oct 31 15:09:07 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julien Grall X-Patchwork-Id: 11221429 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 A812A1390 for ; Thu, 31 Oct 2019 15:11:13 +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 8DC112083E for ; Thu, 31 Oct 2019 15:11:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8DC112083E 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 1iQC54-0006Uw-8d; Thu, 31 Oct 2019 15:09:46 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.89) (envelope-from ) id 1iQC53-0006UR-9z for xen-devel@lists.xenproject.org; Thu, 31 Oct 2019 15:09:45 +0000 X-Inumbo-ID: 754ef15e-fbf0-11e9-954c-12813bfff9fa Received: from foss.arm.com (unknown [217.140.110.172]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTP id 754ef15e-fbf0-11e9-954c-12813bfff9fa; Thu, 31 Oct 2019 15:09:39 +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 C79D646A; Thu, 31 Oct 2019 08:09:38 -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 58BE53F71E; Thu, 31 Oct 2019 08:09:37 -0700 (PDT) From: Julien Grall To: xen-devel@lists.xenproject.org Date: Thu, 31 Oct 2019 15:09:07 +0000 Message-Id: <20191031150922.22938-5-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 04/19] docs/misc: xen-command-line: Rework documentation of the option 'serrors' 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, Stefano Stabellini , Julien Grall , Wei Liu , Konrad Rzeszutek Wilk , George Dunlap , Andrew Cooper , Ian Jackson , Julien Grall , Jan Beulich MIME-Version: 1.0 Errors-To: xen-devel-bounces@lists.xenproject.org Sender: "Xen-devel" The current documentation is misleading for a few reasons: 1) The synchronization happens on all exit/entry from/to the guest. This includes from EL0 (i.e userspace). 2) Trusted guest can also generate SErrors (e.g. memory failure) 3) Without RAS support, SErrors are IMP DEFINED. Unless you have a complete TRM in hand, you can't really make a decision. 4) The documentation is written around performance when this is not the first concern. The documentation is now reworked to focus on the consequences of using serrors="panic" and avoid to go in details on the exact implementation. Signed-off-by: Julien Grall Acked-by: Stefano Stabellini --- TBH, I think this was a mistake to introduce more options without understanding the real use case from the users and the impact. I am not totally against serrors="panic" but I don't think this can be safely used by anyone withtout having a TRM in hand that exhaustively describes all the SErrors. Changes in v4: - Add Stefano's acked-by Changes in v2: - Patch added --- docs/misc/xen-command-line.pandoc | 33 +++++++++------------------------ 1 file changed, 9 insertions(+), 24 deletions(-) diff --git a/docs/misc/xen-command-line.pandoc b/docs/misc/xen-command-line.pandoc index b8a09ce5c4..451d213c8c 100644 --- a/docs/misc/xen-command-line.pandoc +++ b/docs/misc/xen-command-line.pandoc @@ -1854,34 +1854,19 @@ Set the serial transmit buffer size. > Default: `diverse` -This parameter is provided to administrators to determine how the -hypervisors handle SErrors. - -In order to distinguish guest-generated SErrors from hypervisor-generated -SErrors we have to place SError checking code in every EL1 <-> EL2 paths. -That will cause overhead on entries and exits due to dsb/isb. However, not all -platforms need to categorize SErrors. For example, a host that is running with -trusted guests. The administrator can confirm that all guests that are running -on the host will not trigger such SErrors. In this case, the administrator can -use this parameter to skip categorizing SErrors and reduce the overhead of -dsb/isb. - -We provided the following 2 options to administrators to determine how the -hypervisors handle SErrors: +This parameter is provided to administrators to determine how the hypervisor +handles SErrors. * `diverse`: - The hypervisor will distinguish guest SErrors from hypervisor SErrors. - The guest generated SErrors will be forwarded to guests, the hypervisor - generated SErrors will cause the whole system to crash. - It requires: - 1. dsb/isb on all EL1 -> EL2 trap entries to categorize SErrors correctly. - 2. dsb/isb on EL2 -> EL1 return paths to prevent slipping hypervisor - SErrors to guests. + The hypervisor will distinguish guest SErrors from hypervisor SErrors: + - The guest generated SErrors will be forwarded to the currently running + guest. + - The hypervisor generated SErrors will cause the whole system to crash * `panic`: - The hypervisor will not distinguish guest SErrors from hypervisor SErrors. - All SErrors will crash the whole system. This option will avoid all overhead - of the dsb/isb pairs. + All SErrors will cause the whole system to crash. This option should only + be used if you trust all your guests and/or they don't have a gadget (e.g. + device) to generate SErrors in normal run. ### shim_mem (x86) > `= List of ( min: | max: | )`