1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
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.
|
