From nobody Sun Feb 8 19:59:56 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass header.i=dpsmith@apertussolutions.com; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; arc=pass (i=1 dmarc=pass fromdomain=apertussolutions.com) ARC-Seal: i=2; a=rsa-sha256; t=1690906494; cv=pass; d=zohomail.com; s=zohoarc; b=ADEni1w5nixIQpYyQBcJCAP5DKyBWOr2XORy6a35L4iQriR9cFR7ENJchUXPSUsX+TQkuuEj53eiuKY70fmsGnGKuOgJauKODN41vlEF41i809FCUnQ/CXVUfSMtxL2JMx4elrHmQuRYV8KrPnJO+s/5jUw72aR8QwVLOBynrAE= ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1690906494; 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=EW4AyI36gTHVj3MBWRAetoSpPzDjxbKjm9mKfWizXOo=; b=jWSutZzwg2XuH1uVG2VRL5wWyFwP2vgvNT3jpGCV66i8SIrOGiqUtHPpRDUtzj5cT+TITkO3SZgoCBiDrxcDNU2xeSSFh4tsG+7vzgDdLcpAQD0hvRSOgx6gZNnZUOqY3Mg7GYKhvgJXSxck31UiuDFtkjoYb1U/zNbKl7OJTtA= ARC-Authentication-Results: i=2; mx.zohomail.com; dkim=pass header.i=dpsmith@apertussolutions.com; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; arc=pass (i=1 dmarc=pass fromdomain=apertussolutions.com) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 169090649495949.51906543834389; Tue, 1 Aug 2023 09:14:54 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.574421.899676 (Exim 4.92) (envelope-from ) id 1qQs17-0001HT-FS; Tue, 01 Aug 2023 16:14:37 +0000 Received: by outflank-mailman (output) from mailman id 574421.899676; Tue, 01 Aug 2023 16:14:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qQs17-0001HM-CR; Tue, 01 Aug 2023 16:14:37 +0000 Received: by outflank-mailman (input) for mailman id 574421; Tue, 01 Aug 2023 16:14:36 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qQs16-0000zY-4n for xen-devel@lists.xenproject.org; Tue, 01 Aug 2023 16:14:36 +0000 Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com [136.143.188.50]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 80573520-3086-11ee-b25c-6b7b168915f2; Tue, 01 Aug 2023 18:14:34 +0200 (CEST) Received: from sisyou.hme. (static-72-81-132-2.bltmmd.fios.verizon.net [72.81.132.2]) by mx.zohomail.com with SMTPS id 1690906459472812.6746861262045; Tue, 1 Aug 2023 09:14:19 -0700 (PDT) X-Outflank-Mailman: Message body and most headers restored to incoming version X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 80573520-3086-11ee-b25c-6b7b168915f2 ARC-Seal: i=1; a=rsa-sha256; t=1690906461; cv=none; d=zohomail.com; s=zohoarc; b=SpFGSRZv168vMV09mTTWUKEVz9JNfC42MiXsVB2tnQy3YLFfo02HsuyjJ2oon5UwgRk9plmQkm4ntlt1sIBqgxwWPreyCK3QAg/EIA2UTa+yhWh6KgzovOc8/gHjKNHwwnj6bt2yMVI2YCSoNbQbJLeqRlwcazQ413rOA8MTAXw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1690906461; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=EW4AyI36gTHVj3MBWRAetoSpPzDjxbKjm9mKfWizXOo=; b=jY63lARPwfH/uJLrqqVKRDoXDrJycvewxdqi6AboR97Cofj+X1IC5IBabkcytx3ISrwEUl0oZVkclU0ie8cAYkEW25Vf5i9mD5K0/2bzaRvPq3AHvEJfaEf1JerJ1FMWRzgYOKBReAMyVQwfSsZE1Vapwn0VJuulyaZB/mso6xw= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=apertussolutions.com; spf=pass smtp.mailfrom=dpsmith@apertussolutions.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1690906461; s=zoho; d=apertussolutions.com; i=dpsmith@apertussolutions.com; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-Id:Message-Id:In-Reply-To:References:MIME-Version:Content-Type:Content-Transfer-Encoding:Reply-To; bh=EW4AyI36gTHVj3MBWRAetoSpPzDjxbKjm9mKfWizXOo=; b=jUQn0/BiXXca9SaScHVBiryK0BNMviYvvdTIm2fMnlLLX4SUv8JTxzzdfuQQ0Gy2 82R62H8P51oZwrKbx4z+NT7k3RBLVFHMHDSbxEI2tyyGIvXPGMRM/2a2CBHVP2pZkJc zefG+OtHit7OBM9hlsOdO6pm6ixWz8C97C3I07TQ= From: "Daniel P. Smith" To: xen-devel@lists.xenproject.org Cc: "Daniel P. Smith" , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Stefano Stabellini , Wei Liu Subject: [PATCH 1/2] docs: update hyperlaunch device tree Date: Tue, 1 Aug 2023 12:14:08 -0400 Message-Id: <20230801161409.25905-2-dpsmith@apertussolutions.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20230801161409.25905-1-dpsmith@apertussolutions.com> References: <20230801161409.25905-1-dpsmith@apertussolutions.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External X-ZohoMail-DKIM: pass (identity dpsmith@apertussolutions.com) X-ZM-MESSAGEID: 1690906496257100001 With on going development of hyperlaunch, changes to the device tree defini= tions has been necessary. This commit updates the specification for all current c= hanges along with changes expected to be made in finalizing the capability. This commit also adds a HYPERLAUNCH section to the MAINTAINERS file and pla= ces this documentation under its purview. It also reserves the path `xen/common/domain-builder` for the hyperlaunch domain builder code base. Signed-off-by: Daniel P. Smith --- MAINTAINERS | 9 + .../designs/launch/hyperlaunch-devicetree.rst | 566 ++++++++++-------- 2 files changed, 309 insertions(+), 266 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index d8a02a6c19..694412a961 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -332,6 +332,15 @@ M: Nick Rosbrook S: Maintained F: tools/golang =20 +HYPERLAUNCH +M: Daniel P. Smith +M: Christopher Clark +W: https://wiki.xenproject.org/wiki/Hyperlaunch +S: Supported +F: docs/design/launch/hyperlaunch.rst +F: docs/design/launch/hyperlaunch-devicetree.rst +F: xen/common/domain-builder/ + HYPFS M: Juergen Gross S: Supported diff --git a/docs/designs/launch/hyperlaunch-devicetree.rst b/docs/designs/= launch/hyperlaunch-devicetree.rst index b49c98cfbd..0bc719e4ae 100644 --- a/docs/designs/launch/hyperlaunch-devicetree.rst +++ b/docs/designs/launch/hyperlaunch-devicetree.rst @@ -2,10 +2,11 @@ Xen Hyperlaunch Device Tree Bindings ------------------------------------- =20 -The Xen Hyperlaunch device tree adopts the dom0less device tree structure = and -extends it to meet the requirements for the Hyperlaunch capability. The pr= imary -difference is the introduction of the ``hypervisor`` node that is under the -``/chosen`` node. The move to a dedicated node was driven by: +The Xen Hyperlaunch device tree is informed by the dom0less device tree +structure with extensions to meet the requirements for the Hyperlaunch +capability. A major depature from the dom0less device tree is the introduc= tion +of the ``hypervisor`` node that is under the ``/chosen`` node. The move to= a +dedicated node was driven by: =20 1. Reduces the need to walk over nodes that are not of interest, e.g. only nodes of interest should be in ``/chosen/hypervisor`` @@ -13,331 +14,364 @@ difference is the introduction of the ``hypervisor`` = node that is under the 2. Allows for the domain construction information to easily be sanitized by simple removing the ``/chosen/hypervisor`` node. =20 -Example Configuration ---------------------- - -Below are two example device tree definitions for the hypervisor node. The -first is an example of a multiboot-based configuration for x86 and the sec= ond -is a module-based configuration for Arm. - -Multiboot x86 Configuration: -"""""""""""""""""""""""""""" - -:: - - hypervisor { - #address-cells =3D <1>; - #size-cells =3D <0>; - compatible =3D =E2=80=9Chypervisor,xen=E2=80=9D - - // Configuration container - config { - compatible =3D "xen,config"; - - module { - compatible =3D "module,microcode", "multiboot,module"; - mb-index =3D <1>; - }; - - module { - compatible =3D "module,xsm-policy", "multiboot,module"; - mb-index =3D <2>; - }; - }; - - // Boot Domain definition - domain { - compatible =3D "xen,domain"; - - domid =3D <0x7FF5>; - - // FUNCTION_NONE (0) - // FUNCTION_BOOT (1 << 0) - // FUNCTION_CRASH (1 << 1) - // FUNCTION_CONSOLE (1 << 2) - // FUNCTION_XENSTORE (1 << 30) - // FUNCTION_LEGACY_DOM0 (1 << 31) - functions =3D <0x00000001>; - - memory =3D <0x0 0x20000>; - cpus =3D <1>; - module { - compatible =3D "module,kernel", "multiboot,module"; - mb-index =3D <3>; - }; - - module { - compatible =3D "module,ramdisk", "multiboot,module"; - mb-index =3D <4>; - }; - module { - compatible =3D "module,config", "multiboot,module"; - mb-index =3D <5>; - }; - - // Classic Dom0 definition - domain { - compatible =3D "xen,domain"; - - domid =3D <0>; - - // PERMISSION_NONE (0) - // PERMISSION_CONTROL (1 << 0) - // PERMISSION_HARDWARE (1 << 1) - permissions =3D <3>; - - // FUNCTION_NONE (0) - // FUNCTION_BOOT (1 << 0) - // FUNCTION_CRASH (1 << 1) - // FUNCTION_CONSOLE (1 << 2) - // FUNCTION_XENSTORE (1 << 30) - // FUNCTION_LEGACY_DOM0 (1 << 31) - functions =3D <0xC0000006>; - - // MODE_PARAVIRTUALIZED (1 << 0) /* PV | PVH/HVM */ - // MODE_ENABLE_DEVICE_MODEL (1 << 1) /* HVM | PVH */ - // MODE_LONG (1 << 2) /* 64 BIT | 32 BIT */ - mode =3D <5>; /* 64 BIT, PV */ - - // UUID - domain-uuid =3D [B3 FB 98 FB 8F 9F 67 A3]; - - cpus =3D <1>; - memory =3D <0x0 0x20000>; - security-id =3D =E2=80=9Cdom0_t; - - module { - compatible =3D "module,kernel", "multiboot,module"; - mb-index =3D <6>; - bootargs =3D "console=3Dhvc0"; - }; - module { - compatible =3D "module,ramdisk", "multiboot,module"; - mb-index =3D <7>; - }; - }; - -The multiboot modules supplied when using the above config would be, in or= der: +The Hypervisor node +------------------- =20 -* (the above config, compiled) -* CPU microcode -* XSM policy -* kernel for boot domain -* ramdisk for boot domain -* boot domain configuration file -* kernel for the classic dom0 domain -* ramdisk for the classic dom0 domain +The ``hypervisor`` node is a top level container for all information relat= ing +to how the hyperlaunch is to proceed. This includes definitions of the dom= ains +that will be built by hypervisor on start up. The node will be named +``hypervisor`` with a ``compatible`` property to identify which hyperviso= rs +the configuration is intended. The hypervisor node will consist of one or = more +config nodes and one or more domain nodes. =20 -Module Arm Configuration: -""""""""""""""""""""""""" +Properties +"""""""""" =20 -:: +compatible + Identifies which hypervisors the configuration is compatible. Required. =20 - hypervisor { - compatible =3D =E2=80=9Chypervisor,xen=E2=80=9D + Format: "hypervisor,", e.g "hypervisor,xen" =20 - // Configuration container - config { - compatible =3D "xen,config"; +Child Nodes +""""""""""" =20 - module { - compatible =3D "module,microcode=E2=80=9D; - module-addr =3D <0x0000ff00 0x80>; - }; +* config +* domain =20 - module { - compatible =3D "module,xsm-policy"; - module-addr =3D <0x0000ff00 0x80>; +Config Node +----------- =20 - }; - }; +A ``config`` node is for passing configuration data and identifying any bo= ot +modules that is of interest to the hypervisor. For example this would be = where +Xen would be informed of microcode or XSM policy locations. Each ``config`` +node will require a unique device-tree compliant name as there may be one = or +more ``config`` nodes present in a single dtb file. To identify which +hypervisor the configuration is intended, the required ``compatible`` prop= erty +must be present. =20 - // Boot Domain definition - domain { - compatible =3D "xen,domain"; - - domid =3D <0x7FF5>; - - // FUNCTION_NONE (0) - // FUNCTION_BOOT (1 << 0) - // FUNCTION_CRASH (1 << 1) - // FUNCTION_CONSOLE (1 << 2) - // FUNCTION_XENSTORE (1 << 30) - // FUNCTION_LEGACY_DOM0 (1 << 31) - functions =3D <0x00000001>; - - memory =3D <0x0 0x20000>; - cpus =3D <1>; - module { - compatible =3D "module,kernel"; - module-addr =3D <0x0000ff00 0x80>; - }; +While the config node is not meant to replace the hypervisor commandline, = there +may be cases where it is better suited for passing configuration details at +boot time. This additional information may be carried in properties assig= ned +to a ``config`` node. If there are any boot modules that are intended for = the +hypervisor, then a ``module`` child node should be provided to identify the +boot module. =20 - module { - compatible =3D "module,ramdisk"; - module-addr =3D <0x0000ff00 0x80>; - }; - module { - compatible =3D "module,config"; - module-addr =3D <0x0000ff00 0x80>; - }; +Properties +"""""""""" =20 - // Classic Dom0 definition - domain@0 { - compatible =3D "xen,domain"; - - domid =3D <0>; - - // PERMISSION_NONE (0) - // PERMISSION_CONTROL (1 << 0) - // PERMISSION_HARDWARE (1 << 1) - permissions =3D <3>; - - // FUNCTION_NONE (0) - // FUNCTION_BOOT (1 << 0) - // FUNCTION_CRASH (1 << 1) - // FUNCTION_CONSOLE (1 << 2) - // FUNCTION_XENSTORE (1 << 30) - // FUNCTION_LEGACY_DOM0 (1 << 31) - functions =3D <0xC0000006>; - - // MODE_PARAVIRTUALIZED (1 << 0) /* PV | PVH/HVM */ - // MODE_ENABLE_DEVICE_MODEL (1 << 1) /* HVM | PVH */ - // MODE_LONG (1 << 2) /* 64 BIT | 32 BIT */ - mode =3D <5>; /* 64 BIT, PV */ - - // UUID - domain-uuid =3D [B3 FB 98 FB 8F 9F 67 A3]; - - cpus =3D <1>; - memory =3D <0x0 0x20000>; - security-id =3D =E2=80=9Cdom0_t=E2=80=9D; - - module { - compatible =3D "module,kernel"; - module-addr =3D <0x0000ff00 0x80>; - bootargs =3D "console=3Dhvc0"; - }; - module { - compatible =3D "module,ramdisk"; - module-addr =3D <0x0000ff00 0x80>; - }; - }; +compatible + Identifies the hypervisor the confiugration is intended. Required. =20 -The modules that would be supplied when using the above config would be: + Format: ",config", e.g "xen,config" =20 -* (the above config, compiled into hardware tree) -* CPU microcode -* XSM policy -* kernel for boot domain -* ramdisk for boot domain -* boot domain configuration file -* kernel for the classic dom0 domain -* ramdisk for the classic dom0 domain +bootargs + This is used to provide the boot params for Xen. =20 -The hypervisor device tree would be compiled into the hardware device tree= and -provided to Xen using the standard method currently in use. The remaining -modules would need to be loaded in the respective addresses specified in t= he -`module-addr` property. + Format: String, e.g. "flask=3Dsilo" =20 +Child Nodes +""""""""""" =20 -The Hypervisor node -------------------- +* module =20 -The hypervisor node is a top level container for the domains that will be = built -by hypervisor on start up. On the ``hypervisor`` node the ``compatible`` -property is used to identify the type of hypervisor node present.. +Domain Node +----------- =20 -compatible - Identifies the type of node. Required. +A ``domain`` node is for describing the construction of a domain. Since th= ere +may be one or more domain nodes, each one requires a unique, DTB compliant= name +and a ``compatible`` property to identify as a domain node. =20 -The Config node ---------------- +A ``domain`` node may provide a ``domid`` property which will be used as = the +requested domain id for the domain with a value of =E2=80=9C0=E2=80=9D sig= nifying to use the +next available domain id, which is the default behavior if omitted. It sho= uld +be noted that a domain configuration is not able to request a domid of =E2= =80=9C0=E2=80=9D. +Beyond that, a domain node may have any of the following optional properti= es. =20 -A config node is for detailing any modules that are of interest to Xen its= elf. -For example this would be where Xen would be informed of microcode or XSM -policy locations. If the modules are multiboot modules and are able to be -located by index within the module chain, the ``mb-index`` property should= be -used to specify the index in the multiboot module chain.. If the module wi= ll be -located by physical memory address, then the ``module-addr`` property shou= ld be -used to identify the location and size of the module. +Properties +"""""""""" =20 compatible - Identifies the type of node. Required. - -The Domain node ---------------- + Identifies the node as a domain node and for which hypervisor. Required. =20 -A domain node is for describing the construction of a domain. It may provi= de a -domid property which will be used as the requested domain id for the domain -with a value of =E2=80=9C0=E2=80=9D signifying to use the next available d= omain id, which is -the default behavior if omitted. A domain configuration is not able to req= uest -a domid of =E2=80=9C0=E2=80=9D. After that a domain node may have any of t= he following -parameters, - -compatible - Identifies the type of node. Required. + Format: ",domain", e.g "xen,domain" =20 domid - Identifies the domid requested to assign to the domain. Required. + Identifies the domid requested to assign to the domain. =20 -permissions + Format: Integer, e.g <0> + +role This sets what Discretionary Access Control permissions a domain is assigned. Optional, default is none. =20 -functions - This identifies what system functions a domain will fulfill. + Format: Bitfield, e.g <3> or <0x00000003> + + ROLE_NONE (0) + ROLE_UNBOUNDED_DOMAIN (1U<<0) + ROLE_CONTROL_DOMAIN (1U<<1) + ROLE_HARDWARE_DOMAIN (1U<<2) + ROLE_XENSTORE_DOMAIN (1U<<3) + +capability + This identifies what system capabilities a domain may have beyond the ro= le it + was assigned. Optional, the default is none. =20 -.. note:: The `functions` bits that have been selected to indicate - ``FUNCTION_XENSTORE`` and ``FUNCTION_LEGACY_DOM0`` are the last two bits - (30, 31) such that should these features ever be fully retired, the fla= gs may - be dropped without leaving a gap in the flag set. + Format: Bitfield, e.g <3221225487> or <0xC0000007> + + CAP_NONE (0) + CAP_CONSOLE_IO (1U<<0) =20 mode The mode the domain will be executed under. Required. =20 + Format: Bitfield, e.g <5> or <0x00000005> + + MODE_PARAVIRTUALIZED (1 << 0) PV | PVH/HVM + MODE_ENABLE_DEVICE_MODEL (1 << 1) HVM | PVH + MODE_LONG (1 << 2) 64 BIT | 32 BIT + domain-uuid A globally unique identifier for the domain. Optional, the default is NULL. =20 + Format: Byte Array, e.g [B3 FB 98 FB 8F 9F 67 A3] + cpus The number of vCPUs to be assigned to the domain. Optional, the default is =E2=80=9C1=E2=80=9D. =20 + Format: Integer, e.g <0> + memory - The amount of memory to assign to the domain, in KBs. + The amount of memory to assign to the domain, in KBs. This field uses a = DTB + Reg which contains a start and size. For memory allocation start may or = may + not have significance but size will always be used for the amount of mem= ory Required. =20 + Format: String min: | max: | , e.g. "256M" + security-id The security identity to be assigned to the domain when XSM is the access control mechanism being used. Optional, - the default is =E2=80=9Cdomu_t=E2=80=9D. + the default is =E2=80=9Csystem_u:system_r:domU_t=E2=80=9D. + + Format: string, e.g. "system_u:system_r:domU_t" + +Child Nodes +""""""""""" + +* module + +Module node +----------- =20 -The Module node ---------------- +This node describes a boot module loaded by the boot loader. A ``module`` = node +will often appear repeatedly and will require a unique and DTB compliant n= ame +for each instance. The compatible property is required to identify that the +node is a ``module`` node, the type of boot module, and what it represents. =20 -This node describes a boot module loaded by the boot loader. The required -compatible property follows the format: module, where type can be -=E2=80=9Ckernel=E2=80=9D, =E2=80=9Cramdisk=E2=80=9D, =E2=80=9Cdevice-tree= =E2=80=9D, =E2=80=9Cmicrocode=E2=80=9D, =E2=80=9Cxsm-policy=E2=80=9D or =E2= =80=9Cconfig=E2=80=9D. In -the case the module is a multiboot module, the additional property string -=E2=80=9Cmultiboot,module=E2=80=9D may be present. One of two properties i= s required and -identifies how to locate the module. They are the mb-index, used for multi= boot -modules, and the module-addr for memory address based location. +Depending on the type of boot module, the ``module`` node will require eit= her a +``module-index`` or ``module-addr`` property must be present. They provide= the +boot module specific way of locating the boot module in memory. + +Properties +"""""""""" =20 compatible This identifies what the module is and thus what the hypervisor should use the module for during domain construction. Required. =20 -mb-index - This identifies the index for this module in the multiboot module chain. + Format: "module,"[, "module,"] + module type: kernel, ramdisk, device-tree, microcode, xsm-policy, + config + + locating type: index, addr + +module-index + This identifies the index for this module when in a module chain. Required for multiboot environments. =20 + Format: Integer, e.g. <0> + module-addr This identifies where in memory this module is located. Required for non-multiboot environments. =20 + Format: DTB Reg , e.g. <0x0 0x20000> + bootargs This is used to provide the boot params to kernel modules. =20 + Format: String, e.g. "ro quiet" + .. note:: The bootargs property is intended for situations where the same= kernel multiboot module is used for more than one domain. + +Example Configuration +--------------------- + +Below are two example device tree definitions for the hypervisor node. The +first is an example of a multiboot-based configuration for x86 and the sec= ond +is a module-based configuration for Arm. + +Multiboot x86 Configuration: +"""""""""""""""""""""""""""" + +:: + + /dts-v1/; + + / { + chosen { + hypervisor { + compatible =3D "hypervisor,xen", "xen,x86"; + + dom0 { + compatible =3D "xen,domain"; + + domid =3D <0>; + + role =3D <9>; + mode =3D <12>; + + domain-uuid =3D [B3 FB 98 FB 8F 9F 67 A3 8A 6E 62 5A 0= 9 13 F0 8C]; + + cpus =3D <1>; + memory =3D "1024M"; + + kernel { + compatible =3D "module,kernel", "module,index"; + module-index =3D <1>; + }; + + initrd { + compatible =3D "module,ramdisk", "module,index"; + module-index =3D <2>; + }; + }; + + dom1 { + compatible =3D "xen,domain"; + domid =3D <1>; + role =3D <0>; + capability =3D <1>; + mode =3D <12>; + domain-uuid =3D [C2 5D 91 CB 60 4B 45 75 89 04 FF 09 6= 4 54 1A 74]; + cpus =3D <1>; + memory =3D "1024M"; + + kernel { + compatible =3D "module,kernel", "module,index"; + module-index =3D <3>; + bootargs =3D "console=3Dhvc0 earlyprintk=3Dxen roo= t=3D/dev/ram0 rw"; + }; + + initrd { + compatible =3D "module,ramdisk", "module,index"; + module-index =3D <4>; + }; + }; + }; + }; + }; + + + +The multiboot modules supplied when using the above config would be, in or= der: + +* (the above config, compiled) +* kernel for PVH unbounded domain +* ramdisk for PVH unbounded domain +* kernel for PVH guest domain +* ramdisk for PVH guest domain + +Module Arm Configuration: +""""""""""""""""""""""""" + +:: + + /dts-v1/; + + / { + chosen { + hypervisor { + compatible =3D =E2=80=9Chypervisor,xen=E2=80=9D + + // Configuration container + config { + compatible =3D "xen,config"; + + module { + compatible =3D "module,xsm-policy"; + module-addr =3D <0x0000ff00 0x80>; + + }; + }; + + // Unbounded Domain definition + dom0 { + compatible =3D "xen,domain"; + + domid =3D <0>; + + role =3D <9>; + + mode =3D <12>; /* 64 BIT, PVH */ + + memory =3D <0x0 0x20000>; + cpus =3D <1>; + module { + compatible =3D "module,kernel"; + module-addr =3D <0x0000ff00 0x80>; + }; + + module { + compatible =3D "module,ramdisk"; + module-addr =3D <0x0000ff00 0x80>; + }; + + // Guest definition + dom1 { + compatible =3D "xen,domain"; + + domid =3D <0>; + + role =3D <0>; + capability =3D <1>; + + mode =3D <12>; /* 64 BIT, PVH */ + + // UUID + domain-uuid =3D [C2 5D 91 CB 60 4B 45 75 89 04 FF 09 6= 4 54 1A 74]; + + cpus =3D <1>; + memory =3D <0x0 0x20000>; + security-id =3D =E2=80=9Cdom0_t=E2=80=9D; + + module { + compatible =3D "module,kernel"; + module-addr =3D <0x0000ff00 0x80>; + bootargs =3D "console=3Dhvc0"; + }; + module { + compatible =3D "module,ramdisk"; + module-addr =3D <0x0000ff00 0x80>; + }; + }; + }; + }; + }; + +The modules that would be supplied when using the above config would be: + +* (the above config, compiled into hardware tree) +* XSM policy +* kernel for unbounded domain +* ramdisk for unbounded domain +* kernel for guest domain +* ramdisk for guest domain + +The hypervisor device tree would be compiled into the hardware device tree= and +provided to Xen using the standard method currently in use. The remaining +modules would need to be loaded in the respective addresses specified in t= he +`module-addr` property. --=20 2.20.1