From nobody Mon Feb 9 20:10:10 2026 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org ARC-Seal: i=1; a=rsa-sha256; t=1572534652; cv=none; d=zoho.com; s=zohoarc; b=MTAFJcQ6jQo7lYMc84RFGeQ62XXeOEjdTMKV5cVGHEttckOylcQzXAXV/3EFPtX3rr/O+xvpxijCzO3eSw12987AmLyt5xVfyeEydRyfsnpEpeiKsy2Q/qczRg8hWdvoJ6B1hCtWigYEKoEm7Dj3GWaJSpyE0Rg7nwuPD8QCE6c= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1572534652; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:To; bh=MXgrSx+q70ckAQ+5ZzuH+dRcmTCDcqhb6LhQPb1gnvY=; b=Z3YGVAM/WOGUu7yKyeb3tOhvtq0REvFtY/MjPgytJpltvs0PbJnUz2JPr3FF3rFV7LQQytIjr7sSzSTYFawVpeMUy5aDTZz5fpcd81akpki1ZwB+jBfTAnvbhdRzUdyXD+TbiL2PXkYgNmE9Wp3y2XZP95z1mWdbvbsakwRnwA4= ARC-Authentication-Results: i=1; mx.zoho.com; spf=none (zoho.com: 192.237.175.120 is neither permitted nor denied by domain of lists.xenproject.org) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1572534651901557.8771280003197; Thu, 31 Oct 2019 08:10:51 -0700 (PDT) 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 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) X-Inumbo-ID: 754ef15e-fbf0-11e9-954c-12813bfff9fa 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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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=3D"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=3D"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. =20 > Default: `diverse` =20 -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 run= ning -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 hypervis= or +handles SErrors. =20 * `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 correctl= y. - 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 runni= ng + guest. + - The hypervisor generated SErrors will cause the whole system to crash =20 * `panic`: - The hypervisor will not distinguish guest SErrors from hypervisor SError= s. - All SErrors will crash the whole system. This option will avoid all over= head - 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. =20 ### shim_mem (x86) > `=3D List of ( min: | max: | )` --=20 2.11.0 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel