[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Ping: [PATCH v4 2/2] docs/designs/launch: Hyperlaunch device tree
On Thu, May 13, 2021 at 8:41 PM Christopher Clark <christopher.w.clark@xxxxxxxxx> wrote: > > From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx> > > Adds a design document for Hyperlaunch device tree structure. > > Signed-off-by: Christopher Clark <christopher.clark@xxxxxxxxxx> > Signed-off by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx> > --- > .../designs/launch/hyperlaunch-devicetree.rst | 343 ++++++++++++++++++ > 1 file changed, 343 insertions(+) > create mode 100644 docs/designs/launch/hyperlaunch-devicetree.rst > > diff --git a/docs/designs/launch/hyperlaunch-devicetree.rst > b/docs/designs/launch/hyperlaunch-devicetree.rst > new file mode 100644 > index 0000000000..f97d357407 > --- /dev/null > +++ b/docs/designs/launch/hyperlaunch-devicetree.rst > @@ -0,0 +1,343 @@ > +------------------------------------- > +Xen Hyperlaunch Device Tree Bindings > +------------------------------------- > + > +The Xen Hyperlaunch device tree adopts the dom0less device tree structure and > +extends it to meet the requirements for the Hyperlaunch capability. The > primary > +difference is the introduction of the ``hypervisor`` node that is under the > +``/chosen`` node. The move to a dedicated node was driven by: > + > +1. Reduces the need to walk over nodes that are not of interest, e.g. only > + nodes of interest should be in ``/chosen/hypervisor`` > + > +2. Allows for the domain construction information to easily be sanitized by > + simple removing the ``/chosen/hypervisor`` node. > + > +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 second > +is a module-based configuration for Arm. > + > +Multiboot x86 Configuration: > +"""""""""""""""""""""""""""" > + > +:: > + > + hypervisor { > + #address-cells = <1>; > + #size-cells = <0>; > + compatible = “hypervisor,xen” > + > + // Configuration container > + config { > + compatible = "xen,config"; > + > + module { > + compatible = "module,microcode", "multiboot,module"; > + mb-index = <1>; > + }; > + > + module { > + compatible = "module,xsm-policy", "multiboot,module"; > + mb-index = <2>; > + }; > + }; > + > + // Boot Domain definition > + domain { > + compatible = "xen,domain"; > + > + domid = <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 = <0x00000001>; > + > + memory = <0x0 0x20000>; > + cpus = <1>; > + module { > + compatible = "module,kernel", "multiboot,module"; > + mb-index = <3>; > + }; > + > + module { > + compatible = "module,ramdisk", "multiboot,module"; > + mb-index = <4>; > + }; > + module { > + compatible = "module,config", "multiboot,module"; > + mb-index = <5>; > + }; > + > + // Classic Dom0 definition > + domain { > + compatible = "xen,domain"; > + > + domid = <0>; > + > + // PERMISSION_NONE (0) > + // PERMISSION_CONTROL (1 << 0) > + // PERMISSION_HARDWARE (1 << 1) > + permissions = <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 = <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 = <5>; /* 64 BIT, PV */ > + > + // UUID > + domain-uuid = [B3 FB 98 FB 8F 9F 67 A3]; > + > + cpus = <1>; > + memory = <0x0 0x20000>; > + security-id = “dom0_t; > + > + module { > + compatible = "module,kernel", "multiboot,module"; > + mb-index = <6>; > + bootargs = "console=hvc0"; > + }; > + module { > + compatible = "module,ramdisk", "multiboot,module"; > + mb-index = <7>; > + }; > + }; > + > +The multiboot modules supplied when using the above config would be, in > order: > + > +* (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 > + > +Module Arm Configuration: > +""""""""""""""""""""""""" > + > +:: > + > + hypervisor { > + compatible = “hypervisor,xen” > + > + // Configuration container > + config { > + compatible = "xen,config"; > + > + module { > + compatible = "module,microcode”; > + module-addr = <0x0000ff00 0x80>; > + }; > + > + module { > + compatible = "module,xsm-policy"; > + module-addr = <0x0000ff00 0x80>; > + > + }; > + }; > + > + // Boot Domain definition > + domain { > + compatible = "xen,domain"; > + > + domid = <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 = <0x00000001>; > + > + memory = <0x0 0x20000>; > + cpus = <1>; > + module { > + compatible = "module,kernel"; > + module-addr = <0x0000ff00 0x80>; > + }; > + > + module { > + compatible = "module,ramdisk"; > + module-addr = <0x0000ff00 0x80>; > + }; > + module { > + compatible = "module,config"; > + module-addr = <0x0000ff00 0x80>; > + }; > + > + // Classic Dom0 definition > + domain@0 { > + compatible = "xen,domain"; > + > + domid = <0>; > + > + // PERMISSION_NONE (0) > + // PERMISSION_CONTROL (1 << 0) > + // PERMISSION_HARDWARE (1 << 1) > + permissions = <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 = <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 = <5>; /* 64 BIT, PV */ > + > + // UUID > + domain-uuid = [B3 FB 98 FB 8F 9F 67 A3]; > + > + cpus = <1>; > + memory = <0x0 0x20000>; > + security-id = “dom0_t”; > + > + module { > + compatible = "module,kernel"; > + module-addr = <0x0000ff00 0x80>; > + bootargs = "console=hvc0"; > + }; > + module { > + compatible = "module,ramdisk"; > + module-addr = <0x0000ff00 0x80>; > + }; > + }; > + > +The modules that would be supplied when using the above config would be: > + > +* (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 > + > +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 the > +`module-addr` property. > + > + > +The Hypervisor node > +------------------- > + > +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.. > + > +compatible > + Identifies the type of node. Required. > + > +The Config node > +--------------- > + > +A config node is for detailing any modules that are of interest to Xen > itself. > +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 will > be > +located by physical memory address, then the ``module-addr`` property should > be > +used to identify the location and size of the module. > + > +compatible > + Identifies the type of node. Required. > + > +The Domain node > +--------------- > + > +A domain node is for describing the construction of a domain. It may provide > a > +domid property which will be used as the requested domain id for the domain > +with a value of “0” signifying to use the next available domain id, which is > +the default behavior if omitted. A domain configuration is not able to > request > +a domid of “0”. After that a domain node may have any of the following > +parameters, > + > +compatible > + Identifies the type of node. Required. > + > +domid > + Identifies the domid requested to assign to the domain. Required. > + > +permissions > + This sets what Discretionary Access Control permissions > + a domain is assigned. Optional, default is none. > + > +functions > + This identifies what system functions a domain will fulfill. > + Optional, the default is none. > + > +.. 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 flags > may > + be dropped without leaving a gap in the flag set. > + > +mode > + The mode the domain will be executed under. Required. > + > +domain-uuid > + A globally unique identifier for the domain. Optional, > + the default is NULL. > + > +cpus > + The number of vCPUs to be assigned to the domain. Optional, > + the default is “1”. > + > +memory > + The amount of memory to assign to the domain, in KBs. > + Required. > + > +security-id > + The security identity to be assigned to the domain when XSM > + is the access control mechanism being used. Optional, > + the default is “domu_t”. > + > +The Module node > +--------------- > + > +This node describes a boot module loaded by the boot loader. The required > +compatible property follows the format: module,<type> where type can be > +“kernel”, “ramdisk”, “device-tree”, “microcode”, “xsm-policy” or “config”. In > +the case the module is a multiboot module, the additional property string > +“multiboot,module” may be present. One of two properties is required and > +identifies how to locate the module. They are the mb-index, used for > multiboot > +modules, and the module-addr for memory address based location. > + > +compatible > + This identifies what the module is and thus what the hypervisor > + should use the module for during domain construction. Required. > + > +mb-index > + This identifies the index for this module in the multiboot module chain. > + Required for multiboot environments. > + > +module-addr > + This identifies where in memory this module is located. Required for > + non-multiboot environments. > + > +bootargs > + This is used to provide the boot params to kernel modules. > + > +.. note:: The bootargs property is intended for situations where the same > kernel multiboot module is used for more than one domain. > -- > 2.25.1 >
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |