From patchwork Thu Apr 21 11:07:09 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: fu.wei@linaro.org X-Patchwork-Id: 8899271 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 9A8FDBF29F for ; Thu, 21 Apr 2016 11:09:32 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 809812038D for ; Thu, 21 Apr 2016 11:09:28 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 630EE20295 for ; Thu, 21 Apr 2016 11:09:27 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1atCSK-0000pG-0e; Thu, 21 Apr 2016 11:07:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1atCSI-0000pA-4L for xen-devel@lists.xensource.com; Thu, 21 Apr 2016 11:07:30 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id 4E/90-03443-174B8175; Thu, 21 Apr 2016 11:07:29 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRWlGSWpSXmKPExsVysWW7jG7BFol wg4WbDS3uTXnP7sDosb1vF3sAYxRrZl5SfkUCa8asfZ9YCi4KVly8sJ6pgfE9XxcjF4eQwF4m iTULj7NAOKcYJb69e8LWxcjJwSYgLnGm8ysriC0i8INRYuvdmi5GDg5mgTyJBcu1QExhAT+Ju 1PkQCpYBFQl5t48zwwS5hVwlJizmhskLCGgLXG24Rf7BEbOBYwMqxjVi1OLylKLdM30kooy0z NKchMzc3QNDYz1clOLixPTU3MSk4r1kvNzNzECPVXPwMC4g/FKm/MhRkkOJiVR3gXVEuFCfEn 5KZUZicUZ8UWlOanFhxhlODiUJHhvzgPKCRalpqdWpGXmAEMGJi3BwaMkwqs6HyjNW1yQmFuc mQ6ROsWoKCXOywGSEABJZJTmwbXBwvQSo6yUMC8jAwODEE9BalFuZgmq/CtGcQ5GJWHe0yDbe TLzSuCmvwJazAS0mP+uKMjikkSElFQD4/GH3iGpbZUmEz7MsHw6hckk26r9zI4s0TDd5+wyrm wNEQmX/P6337tfPp3vh0Spvo7qxiy9M63ZDnca407phqucjH/wyNVVcd2vkzXXZgn3vrv458y ytXP+ieVWP06LCHtz9rnbxWv1a/aEr0pmlcsrCF3yyHzNr9N+3KLJOQsmuVyV5jr9RImlOCPR UIu5qDgRALmr7VdOAgAA X-Env-Sender: fu.wei@linaro.org X-Msg-Ref: server-13.tower-31.messagelabs.com!1461236847!35559376!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n X-StarScan-Received: X-StarScan-Version: 8.28; banners=-,-,- X-VirusChecked: Checked Received: (qmail 42083 invoked from network); 21 Apr 2016 11:07:28 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-13.tower-31.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 21 Apr 2016 11:07:28 -0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4D1E1C049D52; Thu, 21 Apr 2016 11:07:26 +0000 (UTC) Received: from magi-f23.redhat.com (vpn1-5-104.pek2.redhat.com [10.72.5.104]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3LB7KfY009306; Thu, 21 Apr 2016 07:07:21 -0400 From: fu.wei@linaro.org To: xen-devel@lists.xensource.com, julien.grall@arm.com, sstabellini@kernel.org, dgdegra@tycho.nsa.gov, konrad.wilk@oracle.com, ian.jackson@eu.citrix.com, jbeulich@suse.com, keir@xen.org, tim@xen.org, xen-devel@lists.xen.org Date: Thu, 21 Apr 2016 19:07:09 +0800 Message-Id: <1461236829-11491-1-git-send-email-fu.wei@linaro.org> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Cc: jcm@redhat.com, Fu Wei , leif.lindholm@linaro.org, linaro-uefi@lists.linaro.org Subject: [Xen-devel] [PATCH v2] docs/arm64: update the documention for loading XSM support X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Fu Wei This patch updates the documentation for allowing detection of an XSM module that lacks a specific compatible string. This mechanism has been added by the commit ca32012341f3de7d3975407fb963e6028f0d0c8b. Signed-off-by: Fu Wei Acked-by: Julien Grall --- v2: Improve the doc, according to the suggestion from Julien Grall. v1: http://lists.xen.org/archives/html/xen-devel/2016-04/msg02070.html The first upstream version submitted in xen-devel mailing list. docs/misc/arm/device-tree/booting.txt | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt index ad98bf3..254ba77 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -24,10 +24,24 @@ Each node contains the following properties: string (which must always be present). Xen will assume that the first module which lacks a more - specific compatible string is a "multiboot,kernel" and that - the second such is a "multiboot,ramdisk". Any subsequent - modules which lack a specific compatiblity string will not - receive any special treatment. + specific compatible string is a "multiboot,kernel". + + Xen will check all the modules for the XSM Magic from the second + module that lacks a specific compatible string. According to the + result of the detection: + - if it's a XSM, Xen will assume its compatible string is a + "xen,xsm-policy"; + - if it's not a XSM, for the second module that lacks a specific + compatible string, Xen will assume its compatible string is a + "multiboot,ramdisk"; for the third and subsequent modules those + lacks a specific compatible string will not receive any special + treatment. + This means if the ramdisk module is present and does not have the + compatible string "multiboot,ramdisk", then it must always be the + second module. + Note: This XSM Magic detection behavior was introduced by Xen 4.7. + Xen 4.6 (and downwards) still requires the XSM module to have the + compatible string "xen,xsm-policy". Xen 4.4 supported a different set of legacy compatible strings which remain supported such that systems supporting both 4.4