From nobody Fri May 10 04:18:31 2024 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=1691059532; cv=pass; d=zohomail.com; s=zohoarc; b=ZLr8fAJFqU1qKmArLV/qDiQLMu7E3AwAj6UoYe5kR5//l4IFrL8L+wKxs3H+xenJfdLc3Df8N7qGae56kAETZx2JMtAbolxZzlQ3UuJ1xOnrBSxQ2mZ29/xdmdm4yFrn+uxoVBn8ZtJsF666LYbEdhVVhErstnF2gYBPNtHeoWw= ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1691059532; 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=h2VyWIjGi6oiZ1M8jiK/QXjsBKd98UdO3MNE+MOClEWGP+7ki85mbsnfJ7Luo6P6kSpuvY2JNREsiRacoE4ryJALCYMvqZ0kl17IWFe8XP86L9JeKTRECmGZLEJ3CT2uRF2q2LIk2Tz9qTMAUwZ/Q5tPNaC+WR7cAinCmLArCps= 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 1691059531863390.1510807368777; Thu, 3 Aug 2023 03:45:31 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.576254.902188 (Exim 4.92) (envelope-from ) id 1qRVpS-0006ms-6S; Thu, 03 Aug 2023 10:45:14 +0000 Received: by outflank-mailman (output) from mailman id 576254.902188; Thu, 03 Aug 2023 10:45:14 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qRVpS-0006ml-3D; Thu, 03 Aug 2023 10:45:14 +0000 Received: by outflank-mailman (input) for mailman id 576254; Thu, 03 Aug 2023 10:45:13 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qRVpR-0006R6-2m for xen-devel@lists.xenproject.org; Thu, 03 Aug 2023 10:45:13 +0000 Received: from sender3-of-o58.zoho.com (sender3-of-o58.zoho.com [136.143.184.58]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id d0d3c369-31ea-11ee-8613-37d641c3527e; Thu, 03 Aug 2023 12:45:10 +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 1691059488468459.8456392127623; Thu, 3 Aug 2023 03:44:48 -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: d0d3c369-31ea-11ee-8613-37d641c3527e ARC-Seal: i=1; a=rsa-sha256; t=1691059491; cv=none; d=zohomail.com; s=zohoarc; b=fi5lAjasoGhPJ0xY7+ygV9hjj5fHuhf9L+DPwwBa3aBowixgni8c2Pf+ZIAKBEBc6AqncoCxDkX/9xfVH1Z7tE3f8Xi9mkUBamFX3cFLk4SeV77OleH+YDeD30rkugQOOkLTEw4rf2gFYYZHK4KdolfFO48EjnbC2NjO2RrbXo4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1691059491; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=EW4AyI36gTHVj3MBWRAetoSpPzDjxbKjm9mKfWizXOo=; b=CKGPhBukzRvx6g6gAB58Wx+ZlTCSp6sBl+jTSgoQ1VrnBGbHHR+yYPvoyFCxJJp1F/3t6l72F90bXUcMLhZJELP1JZFF60Wv1VBE6BL11TvkjHKGw1LKsg1ne0MDkkbZkxE2SJOzq42vQgMyNZJ24m3b2+x2+hUtP8Y5kUq9V+Y= 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=1691059491; 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=fVvTEHHmkO6gU+mQHcbeirdwehY3XAMAn+WPEsWkC7a/50e6pWQg0KfP2Hka155e WaTmH106Ia1Ps2E6m9N0ttbmYo3nKp2JAjKUJ+8fhcGRcdV/gL/26aK0b4iq338iQwp WZVzut64+F5ulZebTip4erSy1pwikKUVj3WkuZ5U= 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 v2 1/2] docs: update hyperlaunch device tree Date: Thu, 3 Aug 2023 06:44:37 -0400 Message-Id: <20230803104438.24720-2-dpsmith@apertussolutions.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20230803104438.24720-1-dpsmith@apertussolutions.com> References: <20230803104438.24720-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: 1691059532401100001 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 From nobody Fri May 10 04:18:31 2024 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=1691059551; cv=pass; d=zohomail.com; s=zohoarc; b=H0IXVKsNCMmrneNr5SOFI+FxG7v4LXB87ZOYzxwS4C8LLHOEVb5uQYV2len0mC9sAw1KH/HCSHEl+avh30GzrVALeszwuiDnQ5IQy0jwzedrBaFyM6h0Jo60Zouyl6yBXMWdpoqe1OTTVcE7D9N28SOir4NntsnEAp3I+My3O3k= ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1691059551; h=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=J7499yaTk92ZTF+Y3RPSxthIKYwu2L2+YjjgPAOMoF8=; b=YLBtftcfMnJfAC6oUCX7NEym7BQz6U5oGbzowsZebIrbE7FZZ6869QylnCsaCnRzffRkrDPlz8nkFgjZ9K4YY3joNewu98Yk8oSKTLB5fJ5XnioG3DUAb9Ni0U9pwmVfnemmghssswyhC0sLhK6eG4XbgWi0gWS0bxiFobRuIW4= 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 169105955112097.24091344005797; Thu, 3 Aug 2023 03:45:51 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.576257.902198 (Exim 4.92) (envelope-from ) id 1qRVpn-0007SA-Ga; Thu, 03 Aug 2023 10:45:35 +0000 Received: by outflank-mailman (output) from mailman id 576257.902198; Thu, 03 Aug 2023 10:45:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qRVpn-0007S0-DV; Thu, 03 Aug 2023 10:45:35 +0000 Received: by outflank-mailman (input) for mailman id 576257; Thu, 03 Aug 2023 10:45:34 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1qRVpm-0006R6-FV for xen-devel@lists.xenproject.org; Thu, 03 Aug 2023 10:45:34 +0000 Received: from sender4-of-o50.zoho.com (sender4-of-o50.zoho.com [136.143.188.50]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id dddc5d67-31ea-11ee-8613-37d641c3527e; Thu, 03 Aug 2023 12:45:32 +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 1691059489859266.14813489756693; Thu, 3 Aug 2023 03:44:49 -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: dddc5d67-31ea-11ee-8613-37d641c3527e ARC-Seal: i=1; a=rsa-sha256; t=1691059492; cv=none; d=zohomail.com; s=zohoarc; b=aqV+odTA/piZryJ1RNlX8srNIenVVyn7kqmZEo2Ou5ffwXNUMRJWxnlaFi4IcM4dmfZUPXnZAgxkZgDfi9TKKhdv+b7NqzKe2OeBoiHXvKc391mxHiDAgV5AA3BONVE1meTDzZI2UOkCXkojmVhsD67dsq4V2C+ylc8UGpnVNjc= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1691059492; h=Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=J7499yaTk92ZTF+Y3RPSxthIKYwu2L2+YjjgPAOMoF8=; b=hWYuCKTNnNXnVPC7VrVhK6JG0gIWCTyLYS1eGw/+mflqBVQ/gqHyS4xvbANk3VpTWFmY7d2pquluVNmcxRJvjDQaY4QyJoOtWDdKKliyCF3X5GPNJBZA13QHDPyUqn7fP7ZsARvNnt+12kvDnEMzkjhbNF6WhB1Rj/YbnSyWjO0= 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=1691059492; 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-Transfer-Encoding:Reply-To; bh=J7499yaTk92ZTF+Y3RPSxthIKYwu2L2+YjjgPAOMoF8=; b=aa7Bv6AvRpBeDjO4+OBL9CRK16n/miBWKuWn+MaRMzEpk1ByoYd5SCTdmpDD8L9Z raU+LLrQ37FgN+z/qiB3aP7U/uBlbzC64/EyO4LICu0YhAKKrAvqDtfJRsRhlfVPUIQ vjoqhtLagSuBWggDRFUPAHiNrrZHGBgf6ZryfWfA= From: "Daniel P. Smith" To: Volodymyr Babchuk , xen-devel@lists.xenproject.org Cc: "Daniel P. Smith" , Andrew Cooper , George Dunlap , Jan Beulich , Julien Grall , Stefano Stabellini , Wei Liu , Bertrand Marquis Subject: [PATCH v2 2/2] fdt: make fdt handling reusable across arch Date: Thu, 3 Aug 2023 06:44:38 -0400 Message-Id: <20230803104438.24720-3-dpsmith@apertussolutions.com> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20230803104438.24720-1-dpsmith@apertussolutions.com> References: <20230803104438.24720-1-dpsmith@apertussolutions.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External X-ZohoMail-DKIM: pass (identity dpsmith@apertussolutions.com) X-ZM-MESSAGEID: 1691059552962100001 Content-Type: text/plain; charset="utf-8" This refactors reusable code from Arm's bootfdt.c and device-tree.h that is general fdt handling code. The Kconfig parameter CORE_DEVICE_TREE is introduced for when the ability of parsing DTB files is needed by a capabil= ity such as hyperlaunch. Signed-off-by: Daniel P. Smith Tested-by: Henry Wang --- MAINTAINERS | 8 +- xen/arch/arm/bootfdt.c | 141 +--------------------------- xen/arch/arm/domain_build.c | 1 + xen/arch/arm/include/asm/setup.h | 6 -- xen/common/Kconfig | 4 + xen/common/Makefile | 3 +- xen/common/fdt.c | 153 +++++++++++++++++++++++++++++++ xen/include/xen/device_tree.h | 50 +--------- xen/include/xen/fdt.h | 79 ++++++++++++++++ 9 files changed, 246 insertions(+), 199 deletions(-) create mode 100644 xen/common/fdt.c create mode 100644 xen/include/xen/fdt.h diff --git a/MAINTAINERS b/MAINTAINERS index 694412a961..ad684a2148 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -299,11 +299,13 @@ DEVICE TREE M: Stefano Stabellini M: Julien Grall S: Supported -F: xen/common/libfdt/ F: xen/common/device_tree.c -F: xen/include/xen/libfdt/ -F: xen/include/xen/device_tree.h +F: xen/common/fdt.c +F: xen/common/libfdt/ F: xen/drivers/passthrough/device_tree.c +F: xen/include/xen/device_tree.h +F: xen/include/xen/fdt.h +F: xen/include/xen/libfdt/ =20 ECLAIR R: Simone Ballarin diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c index 2673ad17a1..cdf4f17789 100644 --- a/xen/arch/arm/bootfdt.c +++ b/xen/arch/arm/bootfdt.c @@ -12,79 +12,11 @@ #include #include #include +#include #include #include #include =20 -static bool __init device_tree_node_matches(const void *fdt, int node, - const char *match) -{ - const char *name; - size_t match_len; - - name =3D fdt_get_name(fdt, node, NULL); - match_len =3D strlen(match); - - /* Match both "match" and "match@..." patterns but not - "match-foo". */ - return strncmp(name, match, match_len) =3D=3D 0 - && (name[match_len] =3D=3D '@' || name[match_len] =3D=3D '\0'); -} - -static bool __init device_tree_node_compatible(const void *fdt, int node, - const char *match) -{ - int len, l; - const void *prop; - - prop =3D fdt_getprop(fdt, node, "compatible", &len); - if ( prop =3D=3D NULL ) - return false; - - while ( len > 0 ) { - if ( !dt_compat_cmp(prop, match) ) - return true; - l =3D strlen(prop) + 1; - prop +=3D l; - len -=3D l; - } - - return false; -} - -void __init device_tree_get_reg(const __be32 **cell, uint32_t address_cell= s, - uint32_t size_cells, paddr_t *start, - paddr_t *size) -{ - uint64_t dt_start, dt_size; - - /* - * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit. - * Thus, there is an implicit cast from uint64_t to paddr_t. - */ - dt_start =3D dt_next_cell(address_cells, cell); - dt_size =3D dt_next_cell(size_cells, cell); - - if ( dt_start !=3D (paddr_t)dt_start ) - { - printk("Physical address greater than max width supported\n"); - WARN(); - } - - if ( dt_size !=3D (paddr_t)dt_size ) - { - printk("Physical size greater than max width supported\n"); - WARN(); - } - - /* - * Xen will truncate the address/size if it is greater than the maximum - * supported width and it will give an appropriate warning. - */ - *start =3D dt_start; - *size =3D dt_size; -} - static int __init device_tree_get_meminfo(const void *fdt, int node, const char *prop_name, u32 address_cells, u32 size_cell= s, @@ -135,77 +67,6 @@ static int __init device_tree_get_meminfo(const void *f= dt, int node, return 0; } =20 -u32 __init device_tree_get_u32(const void *fdt, int node, - const char *prop_name, u32 dflt) -{ - const struct fdt_property *prop; - - prop =3D fdt_get_property(fdt, node, prop_name, NULL); - if ( !prop || prop->len < sizeof(u32) ) - return dflt; - - return fdt32_to_cpu(*(uint32_t*)prop->data); -} - -/** - * device_tree_for_each_node - iterate over all device tree sub-nodes - * @fdt: flat device tree. - * @node: parent node to start the search from - * @func: function to call for each sub-node. - * @data: data to pass to @func. - * - * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored. - * - * Returns 0 if all nodes were iterated over successfully. If @func - * returns a value different from 0, that value is returned immediately. - */ -int __init device_tree_for_each_node(const void *fdt, int node, - device_tree_node_func func, - void *data) -{ - /* - * We only care about relative depth increments, assume depth of - * node is 0 for simplicity. - */ - int depth =3D 0; - const int first_node =3D node; - u32 address_cells[DEVICE_TREE_MAX_DEPTH]; - u32 size_cells[DEVICE_TREE_MAX_DEPTH]; - int ret; - - do { - const char *name =3D fdt_get_name(fdt, node, NULL); - u32 as, ss; - - if ( depth >=3D DEVICE_TREE_MAX_DEPTH ) - { - printk("Warning: device tree node `%s' is nested too deep\n", - name); - continue; - } - - as =3D depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELL= S_DEFAULT; - ss =3D depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_D= EFAULT; - - address_cells[depth] =3D device_tree_get_u32(fdt, node, - "#address-cells", as); - size_cells[depth] =3D device_tree_get_u32(fdt, node, - "#size-cells", ss); - - /* skip the first node */ - if ( node !=3D first_node ) - { - ret =3D func(fdt, node, name, depth, as, ss, data); - if ( ret !=3D 0 ) - return ret; - } - - node =3D fdt_next_node(fdt, node, &depth); - } while ( node >=3D 0 && depth > 0 ); - - return 0; -} - static int __init process_memory_node(const void *fdt, int node, const char *name, int depth, u32 address_cells, u32 size_cells, diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c index 39b4ee03a5..7bd6c009d1 100644 --- a/xen/arch/arm/domain_build.c +++ b/xen/arch/arm/domain_build.c @@ -30,6 +30,7 @@ #include #include #include +#include =20 #include #include diff --git a/xen/arch/arm/include/asm/setup.h b/xen/arch/arm/include/asm/se= tup.h index 19dc637d55..ae2bfcc7e6 100644 --- a/xen/arch/arm/include/asm/setup.h +++ b/xen/arch/arm/include/asm/setup.h @@ -159,12 +159,6 @@ const char *boot_module_kind_as_string(bootmodule_kind= kind); extern uint32_t hyp_traps_vector[]; void init_traps(void); =20 -void device_tree_get_reg(const __be32 **cell, uint32_t address_cells, - uint32_t size_cells, paddr_t *start, paddr_t *siz= e); - -u32 device_tree_get_u32(const void *fdt, int node, - const char *prop_name, u32 dflt); - int map_range_to_domain(const struct dt_device_node *dev, uint64_t addr, uint64_t len, void *data); =20 diff --git a/xen/common/Kconfig b/xen/common/Kconfig index 0d248ab941..e2fdb3cbc3 100644 --- a/xen/common/Kconfig +++ b/xen/common/Kconfig @@ -38,8 +38,12 @@ config HAS_ALTERNATIVE config HAS_COMPAT bool =20 +config CORE_DEVICE_TREE + bool + config HAS_DEVICE_TREE bool + select CORE_DEVICE_TREE =20 config HAS_EX_TABLE bool diff --git a/xen/common/Makefile b/xen/common/Makefile index 46049eac35..fd3769e1c6 100644 --- a/xen/common/Makefile +++ b/xen/common/Makefile @@ -11,6 +11,7 @@ obj-y +=3D domain.o obj-y +=3D event_2l.o obj-y +=3D event_channel.o obj-y +=3D event_fifo.o +obj-$(CONFIG_CORE_DEVICE_TREE) +=3D fdt.o obj-$(CONFIG_CRASH_DEBUG) +=3D gdbstub.o obj-$(CONFIG_GRANT_TABLE) +=3D grant_table.o obj-y +=3D guestcopy.o @@ -75,7 +76,7 @@ obj-y +=3D sched/ obj-$(CONFIG_UBSAN) +=3D ubsan/ =20 obj-$(CONFIG_NEEDS_LIBELF) +=3D libelf/ -obj-$(CONFIG_HAS_DEVICE_TREE) +=3D libfdt/ +obj-$(CONFIG_CORE_DEVICE_TREE) +=3D libfdt/ =20 CONF_FILE :=3D $(if $(patsubst /%,,$(KCONFIG_CONFIG)),$(objtree)/)$(KCONFI= G_CONFIG) $(obj)/config.gz: $(CONF_FILE) diff --git a/xen/common/fdt.c b/xen/common/fdt.c new file mode 100644 index 0000000000..8d7acaaa43 --- /dev/null +++ b/xen/common/fdt.c @@ -0,0 +1,153 @@ +/* + * Flattened Device Tree + * + * Copyright (C) 2012-2014 Citrix Systems, Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#include +#include +#include +#include +#include + +bool __init device_tree_node_matches( + const void *fdt, int node, const char *match) +{ + const char *name; + size_t match_len; + + name =3D fdt_get_name(fdt, node, NULL); + match_len =3D strlen(match); + + /* Match both "match" and "match@..." patterns but not + "match-foo". */ + return strncmp(name, match, match_len) =3D=3D 0 + && (name[match_len] =3D=3D '@' || name[match_len] =3D=3D '\0'); +} + +bool __init device_tree_node_compatible( + const void *fdt, int node, const char *match) +{ + int len, l; + const void *prop; + + prop =3D fdt_getprop(fdt, node, "compatible", &len); + if ( prop =3D=3D NULL ) + return false; + + while ( len > 0 ) { + if ( !dt_compat_cmp(prop, match) ) + return true; + l =3D strlen(prop) + 1; + prop +=3D l; + len -=3D l; + } + + return false; +} + +void __init device_tree_get_reg( + const __be32 **cell, uint32_t address_cells, uint32_t size_cells, + paddr_t *start, paddr_t *size) +{ + uint64_t dt_start, dt_size; + + /* + * dt_next_cell will return uint64_t whereas paddr_t may not be 64-bit. + * Thus, there is an implicit cast from uint64_t to paddr_t. + */ + dt_start =3D dt_next_cell(address_cells, cell); + dt_size =3D dt_next_cell(size_cells, cell); + + if ( dt_start !=3D (paddr_t)dt_start ) + { + printk("Physical address greater than max width supported\n"); + WARN(); + } + + if ( dt_size !=3D (paddr_t)dt_size ) + { + printk("Physical size greater than max width supported\n"); + WARN(); + } + + /* + * Xen will truncate the address/size if it is greater than the maximum + * supported width and it will give an appropriate warning. + */ + *start =3D dt_start; + *size =3D dt_size; +} + +u32 __init device_tree_get_u32( + const void *fdt, int node, const char *prop_name, u32 dflt) +{ + const struct fdt_property *prop; + + prop =3D fdt_get_property(fdt, node, prop_name, NULL); + if ( !prop || prop->len < sizeof(u32) ) + return dflt; + + return fdt32_to_cpu(*(uint32_t*)prop->data); +} + +/** + * device_tree_for_each_node - iterate over all device tree sub-nodes + * @fdt: flat device tree. + * @node: parent node to start the search from + * @func: function to call for each sub-node. + * @data: data to pass to @func. + * + * Any nodes nested at DEVICE_TREE_MAX_DEPTH or deeper are ignored. + * + * Returns 0 if all nodes were iterated over successfully. If @func + * returns a value different from 0, that value is returned immediately. + */ +int __init device_tree_for_each_node( + const void *fdt, int node, device_tree_node_func func, void *data) +{ + /* + * We only care about relative depth increments, assume depth of + * node is 0 for simplicity. + */ + int depth =3D 0; + const int first_node =3D node; + u32 address_cells[DEVICE_TREE_MAX_DEPTH]; + u32 size_cells[DEVICE_TREE_MAX_DEPTH]; + int ret; + + do { + const char *name =3D fdt_get_name(fdt, node, NULL); + u32 as, ss; + + if ( depth >=3D DEVICE_TREE_MAX_DEPTH ) + { + printk("Warning: device tree node `%s' is nested too deep\n", + name); + continue; + } + + as =3D depth > 0 ? address_cells[depth-1] : DT_ROOT_NODE_ADDR_CELL= S_DEFAULT; + ss =3D depth > 0 ? size_cells[depth-1] : DT_ROOT_NODE_SIZE_CELLS_D= EFAULT; + + address_cells[depth] =3D device_tree_get_u32(fdt, node, + "#address-cells", as); + size_cells[depth] =3D device_tree_get_u32(fdt, node, + "#size-cells", ss); + + /* skip the first node */ + if ( node !=3D first_node ) + { + ret =3D func(fdt, node, name, depth, as, ss, data); + if ( ret !=3D 0 ) + return ret; + } + + node =3D fdt_next_node(fdt, node, &depth); + } while ( node >=3D 0 && depth > 0 ); + + return 0; +} diff --git a/xen/include/xen/device_tree.h b/xen/include/xen/device_tree.h index 1d79e23b28..82db38b140 100644 --- a/xen/include/xen/device_tree.h +++ b/xen/include/xen/device_tree.h @@ -14,13 +14,12 @@ #include #include #include +#include #include #include #include #include =20 -#define DEVICE_TREE_MAX_DEPTH 16 - /* * Struct used for matching a device */ @@ -159,17 +158,8 @@ struct dt_raw_irq { u32 specifier[DT_MAX_IRQ_SPEC]; }; =20 -typedef int (*device_tree_node_func)(const void *fdt, - int node, const char *name, int depth, - u32 address_cells, u32 size_cells, - void *data); - extern const void *device_tree_flattened; =20 -int device_tree_for_each_node(const void *fdt, int node, - device_tree_node_func func, - void *data); - /** * dt_unflatten_host_device_tree - Unflatten the host device tree * @@ -214,14 +204,6 @@ extern const struct dt_device_node *dt_interrupt_contr= oller; struct dt_device_node * dt_find_interrupt_controller(const struct dt_device_match *matches); =20 -#define dt_prop_cmp(s1, s2) strcmp((s1), (s2)) -#define dt_node_cmp(s1, s2) strcasecmp((s1), (s2)) -#define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2)) - -/* Default #address and #size cells */ -#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2 -#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1 - #define dt_for_each_property_node(dn, pp) \ for ( pp =3D (dn)->properties; (pp) !=3D NULL; pp =3D (pp)->next ) =20 @@ -231,16 +213,6 @@ dt_find_interrupt_controller(const struct dt_device_ma= tch *matches); #define dt_for_each_child_node(dt, dn) \ for ( dn =3D (dt)->child; (dn) !=3D NULL; dn =3D (dn)->sibling ) =20 -/* Helper to read a big number; size is in cells (not bytes) */ -static inline u64 dt_read_number(const __be32 *cell, int size) -{ - u64 r =3D 0; - - while ( size-- ) - r =3D (r << 32) | be32_to_cpu(*(cell++)); - return r; -} - /* Wrapper for dt_read_number() to return paddr_t (instead of uint64_t) */ static inline paddr_t dt_read_paddr(const __be32 *cell, int size) { @@ -268,26 +240,6 @@ static inline paddr_t dt_read_paddr(const __be32 *cell= , int size) return r; } =20 -/* Helper to convert a number of cells to bytes */ -static inline int dt_cells_to_size(int size) -{ - return (size * sizeof (u32)); -} - -/* Helper to convert a number of bytes to cells, rounds down */ -static inline int dt_size_to_cells(int bytes) -{ - return (bytes / sizeof(u32)); -} - -static inline u64 dt_next_cell(int s, const __be32 **cellp) -{ - const __be32 *p =3D *cellp; - - *cellp =3D p + s; - return dt_read_number(p, s); -} - static inline const char *dt_node_full_name(const struct dt_device_node *n= p) { return (np && np->full_name) ? np->full_name : ""; diff --git a/xen/include/xen/fdt.h b/xen/include/xen/fdt.h new file mode 100644 index 0000000000..00ae6a5c8b --- /dev/null +++ b/xen/include/xen/fdt.h @@ -0,0 +1,79 @@ +/* + * Flattened Device Tree + * + * Copyright (C) 2012 Citrix Systems, Inc. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#ifndef __XEN_FDT_H__ +#define __XEN_FDT_H__ + +#include +#include +#include + +#define DEVICE_TREE_MAX_DEPTH 16 + +/* Default #address and #size cells */ +#define DT_ROOT_NODE_ADDR_CELLS_DEFAULT 2 +#define DT_ROOT_NODE_SIZE_CELLS_DEFAULT 1 + +#define dt_prop_cmp(s1, s2) strcmp((s1), (s2)) +#define dt_node_cmp(s1, s2) strcasecmp((s1), (s2)) +#define dt_compat_cmp(s1, s2) strcasecmp((s1), (s2)) + +/* Helper to read a big number; size is in cells (not bytes) */ +static inline u64 dt_read_number(const __be32 *cell, int size) +{ + u64 r =3D 0; + + while ( size-- ) + r =3D (r << 32) | be32_to_cpu(*(cell++)); + return r; +} + +/* Helper to convert a number of cells to bytes */ +static inline int dt_cells_to_size(int size) +{ + return (size * sizeof (u32)); +} + +/* Helper to convert a number of bytes to cells, rounds down */ +static inline int dt_size_to_cells(int bytes) +{ + return (bytes / sizeof(u32)); +} + +static inline u64 dt_next_cell(int s, const __be32 **cellp) +{ + const __be32 *p =3D *cellp; + + *cellp =3D p + s; + return dt_read_number(p, s); +} + + +bool device_tree_node_matches( + const void *fdt, int node, const char *match); + +bool device_tree_node_compatible( + const void *fdt, int node, const char *match); + +void device_tree_get_reg( + const __be32 **cell, u32 address_cells, u32 size_cells, u64 *start, + u64 *size); + +u32 device_tree_get_u32( + const void *fdt, int node, const char *prop_name, u32 dflt); + +typedef int (*device_tree_node_func)( + const void *fdt, int node, const char *name, int depth, u32 address_ce= lls, + u32 size_cells, void *data); + +int device_tree_for_each_node( + const void *fdt, int node, device_tree_node_func func, void *data); + + +#endif /* __XEN_FDT_H__ */ --=20 2.20.1