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: 178196 Delivered-To: patch@linaro.org Received: by 2002:a92:409a:0:0:0:0:0 with SMTP id d26csp2980114ill; Thu, 31 Oct 2019 08:11:15 -0700 (PDT) X-Google-Smtp-Source: APXvYqy0gE3437IYufxb8gBmKfchROiYpMHa+nY/4guZ6xeOvsy9KPSSNYKbToICVP9k2oRQ2tTJ X-Received: by 2002:a6b:3707:: with SMTP id e7mr5702459ioa.293.1572534675660; Thu, 31 Oct 2019 08:11:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572534675; cv=none; d=google.com; s=arc-20160816; b=iRB6yi8zskw2M9nsdevF0GyvIYDynBQoveiWy0YqZSOjd0o4zUw1/liJfY1D0K9UCb cE1bsF01JETu7RHkd2UqIDS6tWfv0IbqmjhNPcjpXZp4p6urS/xMyAKz+8aSKei3MCLy Ppz6F02tn1Dj5M6Q8FSb0bpf/SY4x5pP4Dy0V3wsausCTW7TQAcTuzCs9+KlgFxOsqL+ 5W7ykKuB+y7zB/06yrSvix823+EUbGwItETCSJZ/rUjCUb3jvCqEGtJta4NCyQ3JyVry lJUVHsIPsYRLnhJYYr6QQMGBPUrRA2+ptbnP6lDH2A/J4m+vN4ZYnhcgke63D0MU+jhk HRAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:content-transfer-encoding:mime-version:cc :list-subscribe:list-help:list-post:list-unsubscribe:list-id :precedence:subject:references:in-reply-to:message-id:date:to:from; bh=MXgrSx+q70ckAQ+5ZzuH+dRcmTCDcqhb6LhQPb1gnvY=; b=YK/w7qIciw9/mp1nAg9OST3L+RuOpIObjI6R7R34rHH0FbQIHCSYOHVUKYI4Sd/5J9 Weh89zT+u0BjZvSPlHtVmZy9KEdB6sp25FUtHmudzOcQ6HgUg35qyk5e+LmAT99uASH9 A+hSfHiZDTPmuQyGV+EHCd34xKKzEXC/6bjxViNofLevVC1+OijayXTKX90PBt1BuQQz aRF/FtRhHpSlN/tCF3MihN4EEyUqV4PStiqvn7M98AJo45fXx+/PqXsQefSdD4wk7shT vsjgVsh9x+Xh1Je+D0cdhDTBRivW/ZhdxDQovGxboEhs6PnA7weela05hEST3xvdaHUH 2eIQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of xen-devel-bounces@lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org. [192.237.175.120]) by mx.google.com with ESMTPS id i8si7202933ioa.56.2019.10.31.08.11.15 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 31 Oct 2019 08:11:15 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of xen-devel-bounces@lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of xen-devel-bounces@lists.xenproject.org designates 192.237.175.120 as permitted sender) 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: | )`