1# XenStore Paths
2
3This document attempts to defines all the paths which are in common
4use by either guests, front-/back-end drivers, toolstacks etc.
5
6The XenStore wire protocol itself is described in
7[xenstore.txt](xenstore.txt).
8
9## Notation
10
11This document is intended to be partially machine readable, such that
12test system etc can use it to validate whether the xenstore paths used
13by a test are allowable etc.
14
15Therefore the following notation conventions apply:
16
17A xenstore path is generically defined as:
18
19        PATH = VALUES [TAGS]
20
21        PATH/* [TAGS]
22
23The first syntax defines a simple path with a single value. The second
24syntax defines an aggregated set of paths which are usually described
25externally to this document. The text will give a pointer to the
26appropriate external documentation.
27
28PATH can contain simple regex constructs following the Perl compatible
29regexp syntax described in pcre(3) or perlre(1). In addition the
30following additional wild card names are defined and are evaluated
31before regexp expansion:
32
33* ~ -- expands to an arbitrary a domain's home path (described below).
34  Only valid at the begining of a path.
35* $DEVID -- a per-device type device identifier. Typically an integer.
36* $DOMID -- a domain identifier, an integer. Typically this refers to
37  the "other" domain. i.e. ~ refers to the domain providing a service
38  while $DOMID is the consumer of that service.
39* $UUID -- a UUID in the form xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
40* $INDEX -- an integer used as part of a path when listing a set of
41            values. Typically these integers are contiguous.
42
43VALUES are strings and can take the following forms:
44
45* PATH -- a XenStore path.
46* STRING -- an arbitrary string.
47* INTEGER -- An integer, in decimal representation unless otherwise
48  noted.
49 * MEMKB -- the decimal representation of a number of kilobytes.
50 * EVTCHN -- the decimal representation of an event channel.
51 * GNTREF -- the decimal representation of a grant reference.
52* "a literal string" -- literal strings are contained within quotes.
53* (VALUE | VALUE | ... ) -- a set of alternatives. Alternatives are
54  separated by a "|" and all the alternatives are enclosed in "(" and
55  ")".
56* DISTRIBUTION -- information about a software distribution, comprised
57                  of 3 or 4 space separated UTF-8 strings as follows:
58
59                  VENDOR -- Commonly used vendor short name,
60                            e.g "Citrix" rather than "Citrix Systems
61                            Inc."
62
63                  PRODUCT -- Commonly used product (e.g. driver) name
64                             without version information.
65
66                  If the toolstack needs to match on either of the above
67                  values it should support Unix glob style matching.
68
69                  VERSION -- A version number that will sort properly
70                             under coreutils version sorting (sort -V)
71                             rules.
72
73                  ATTRIBUTES -- Optional human readable text to denote
74                                attributes of the software, e.g. "debug".
75                                This text is freeform and no meaning
76                                should be inferred. It is intended for
77                                display purposes only.
78
79* MAC_ADDRESS -- 6 integers, in hexadecimal form, separated by ':',
80                 specifying an IEEE 802.3 ethernet MAC address.
81* IPV4_ADDRESS -- 4 integers, in decimal form, separated by '.',
82                  specifying an IP version 4 address as described
83                  IETF RFC 791.
84* IPV6_ADDRESS -- Up to 8 integers, in hexadecimal form, separated
85                  by ':', specifying an IP version 6 address as
86                  described in IETF RFC 4291.
87
88Additional TAGS may follow as a comma separated set of the following
89tags enclosed in square brackets.
90
91* w -- Path is writable by the containing domain, that is the domain
92  whose home path ~ this key is under or which /vm/$UUID refers to. By
93  default paths under both of these locations are read only for the
94  domain.
95* n -- Path is neither readable nor writeable for guest domains.
96* HVM -- Path is valid for HVM domains only
97* PV --  Path is valid for PV domains only
98* BACKEND -- Path is valid for a backend domain (AKA driver domain)
99* INTERNAL -- Although a path is visible to the domain its use is
100  reserved for the virtual firmware or Xen platform code. Guest
101  Operating Systems must not read this key or otherwise rely on its
102  presence or contents.
103* DEPRECATED -- This path is deprecated and may be removed in its
104  current form in the future. Guests should not add new dependencies
105  on such paths.
106
107Owning domain means the domain whose home path this tag is found
108under.
109
110Lack of either a __HVM__ or __PV__ tag indicates that the path is
111valid for either type of domain (including PVonHVM and similar mixed
112domain types).
113
114## Domain Home Path
115
116Every domain has a home path within the xenstore hierarchy. This is
117the path where the majority of the domain-visible information about
118each domain is stored.
119
120This path is:
121
122      /local/domain/$DOMID
123
124All non-absolute paths are relative to this path.
125
126Although this path could be considered a "Home Directory" for the
127domain it would not usually be writable by the domain. The tools will
128create writable subdirectories as necessary.
129
130## Per Domain Paths
131
132## General Paths
133
134#### ~/vm = PATH []
135
136A pointer back to the domain's /vm/$UUID path (described below).
137
138#### ~/name = STRING []
139
140The guests name.
141
142#### ~/domid = INTEGER   []
143
144The domain's own ID.
145
146#### ~/image/device-model-pid = INTEGER   [INTERNAL]
147
148The process ID of the device model associated with this domain, if it
149has one.
150
151#### ~/image/device-model-domid = INTEGER   [INTERNAL]
152
153The domain ID of the device model stubdomain associated with this domain,
154if it has one.
155
156#### ~/cpu/[0-9]+/availability = ("online"|"offline") [PV]
157
158One node for each virtual CPU up to the guest's configured
159maximum. Valid values are "online" and "offline". The guest is expected to react to changes in this path by bringing the appropriate VCPU on or offline using the VCPUOP interface described in [xen/include/public/vcpu.h][VCPU]
160
161This protocol is not currently well documented.
162
163#### ~/memory/static-max = MEMKB []
164
165Specifies a static maximum amount memory which this domain should
166expect to be given. In the absence of in-guest memory hotplug support
167this set on domain boot and is usually the maximum amount of RAM which
168a guest can make use of. See [docs/misc/libxl_memory.txt][LIBXLMEM]
169for a description of how memory is accounted for in toolstacks using
170the libxl library.
171
172#### ~/memory/target = MEMKB []
173
174The current balloon target for the domain. The balloon driver within
175the guest is expected to make every effort to every effort use no more
176than this amount of RAM.
177
178#### ~/memory/videoram = MEMKB [HVM,INTERNAL]
179
180The size of the video RAM this domain is configured with.
181
182#### ~/device/suspend/event-channel = ""|EVTCHN [w]
183
184The domain's suspend event channel. The toolstack may create this
185path with an empty value which the guest may choose to overwrite. If
186the path does not exist then the ~/device path will be writable by the
187guest and hence it may create the suspend event channel path.
188
189If the guest writes this, it will be with the number of an unbound
190event channel port it has acquired.  The toolstack is expected to use
191an interdomain bind, and then, when it wishes to ask the guest to
192suspend, to signal the event channel.
193
194The guest does not need to explicitly acknowledge the request; indeed,
195there is no explicit signalling by the guest in the reverse direction.
196The guest, when it is ready, simply shuts down (`SCHEDOP_shutdown`)
197with reason code `SHUTDOWN_suspend`.  The toolstack is expected to use
198`XEN_DOMCTL_subscribe` to be alerted to guest state changes, and
199`XEN_SYSCTL_getdomaininfolist` to verify that the domain has
200suspended.
201
202Note that the use of this event channel suspend protocol is optional
203for both sides.  By writing a non-empty string to the node, the guest
204is advertising its support.  However, the toolstack is at liberty to
205use the xenstore-based protocol instead (see ~/control/shutdown,
206below) even if the guest has advertised support for the event channel
207protocol.
208
209#### ~/hvmloader/allow-memory-relocate = ("1"|"0") [HVM,INTERNAL]
210
211If the default low MMIO hole (below 4GiB) is not big enough for all
212the devices, this indicates if hvmloader should relocate guest memory
213into the high memory region (above 4GiB).  If "1", hvmloader will
214relocate memory as needed, until 2GiB is reached; if "0", hvmloader
215will not relocate guest memory.
216
217#### ~/hvmloader/bios = ("rombios"|"seabios"|"OVMF") [HVM,INTERNAL]
218
219The BIOS used by this domain.
220
221#### ~/bios-strings/bios-vendor = STRING [HVM,INTERNAL]
222#### ~/bios-strings/bios-version = STRING [HVM,INTERNAL]
223#### ~/bios-strings/system-manufacturer = STRING [HVM,INTERNAL]
224#### ~/bios-strings/system-product-name = STRING [HVM,INTERNAL]
225#### ~/bios-strings/system-version = STRING [HVM,INTERNAL]
226#### ~/bios-strings/system-serial-number = STRING [HVM,INTERNAL]
227#### ~/bios-strings/enclosure-manufacturer = STRING [HVM,INTERNAL]
228#### ~/bios-strings/enclosure-serial-number = STRING [HVM,INTERNAL]
229#### ~/bios-strings/enclosure-asset-tag = STRING [HVM,INTERNAL]
230#### ~/bios-strings/battery-manufacturer = STRING [HVM,INTERNAL]
231#### ~/bios-strings/battery-device-name = STRING [HVM,INTERNAL]
232
233These xenstore values are used to override some of the default string
234values in the SMBIOS table constructed in hvmloader. See the SMBIOS
235table specification at http://www.dmtf.org/standards/smbios/
236
237#### ~/bios-strings/oem-* = STRING [HVM,INTERNAL]
238
2391 to 99 OEM strings can be set in xenstore using values of the form
240'~/bios-strings/oem-1' to '~/bios-strings/oem-99'. These strings will be
241loaded into the SMBIOS type 11 structure.
242
243#### ~/platform/* = ("0"|"1") [HVM,INTERNAL]
244
245Various boolean platform properties.
246
247* acpi -- is ACPI enabled for this domain
248* acpi_s3 -- is ACPI S3 support enabled for this domain
249* acpi_s4 -- is ACPI S4 support enabled for this domain
250* acpi_laptop_slate -- is the ACPI laptop/slate device present in
251                       this domain
252
253#### ~/platform/generation-id = INTEGER ":" INTEGER [HVM,INTERNAL]
254
255The lower and upper 64-bit words of the 128-bit VM Generation ID.
256
257This key is used by hvmloader to create the ACPI VM Generation ID
258device.  It initialises a 16 octet region of guest memory with this
259value.  The guest physical address of this region is saved in the
260HVM_PARAM_VM_GENERATION_ID_ADDR HVM parameter.
261
262If this key is not present, is empty, or is all-zeros ("0:0") then the
263ACPI device is not created.
264
265When restoring a guest, the toolstack may (in certain circumstances)
266need generate a new random generation ID and write it to guest memory
267at the guest physical address in HVM_PARAM_VM_GENERATION_ID_ADDR.
268
269See Microsoft's "Virtual Machine Generation ID" specification for the
270circumstances where the generation ID needs to be changed.
271
272### Frontend device paths
273
274Paravirtual device frontends are generally specified by their own
275directory within the XenStore hierarchy. Usually this is under
276~/device/$TYPE/$DEVID although there are exceptions, e.g. ~/console
277for the first PV console. The top level ~/device path itself is normally
278read-only to the guest. However it may writable if the
279'xend_suspend_evtchn_compat' guest configuration option is enabled.
280
281#### ~/device/vbd/$DEVID/* []
282
283A virtual block device frontend. Described by
284[xen/include/public/io/blkif.h][BLKIF]
285
286#### ~/device/vfb/$DEVID/* []
287
288A virtual framebuffer frontend. Described by
289[xen/include/public/io/fbif.h][FBIF]
290
291#### ~/device/vkbd/$DEVID/* []
292
293A virtual keyboard device frontend. Described by
294[xen/include/public/io/kbdif.h][KBDIF]
295
296#### ~/device/vif/$DEVID/* []
297
298A virtual network device frontend. Described by
299[xen/include/public/io/netif.h][NETIF]
300
301#### ~/device/vscsi/$DEVID/* []
302
303A virtual scsi device frontend. Described by
304[xen/include/public/io/vscsiif.h][SCSIIF]
305
306#### ~/device/vusb/$DEVID/* []
307
308A virtual usb device frontend. Described by
309[xen/include/public/io/usbif.h][USBIF]
310
311#### ~/device/pvcalls/$DEVID/* []
312
313Paravirtualized POSIX function calls frontend. Described by
314[docs/misc/pvcalls.markdown][PVCALLS]
315
316#### ~/console/* []
317
318The primary PV console device. Described in [console.txt](console.txt)
319
320#### ~/device/console/$DEVID/* []
321
322A secondary PV console device. Described in [console.txt](console.txt)
323
324#### ~/serial/$DEVID/* [HVM]
325
326An emulated serial device. Described in [console.txt](console.txt)
327
328#### ~/store/port = EVTCHN [DEPRECATED]
329
330The event channel used by the domain's connection to XenStore.
331
332This path is deprecated since the same information is provided via the
333[start_info][SI] for PV guests and as an [HVM param][HVMPARAMS] for
334HVM guests. There is an obvious chicken and egg problem with
335extracting this value from xenstore in order to setup the xenstore
336communication ring.
337
338#### ~/store/ring-ref = GNTREF [DEPRECATED]
339
340The grant reference of the domain's XenStore ring.
341
342As with ~/store/port this path is deprecated.
343
344### Backend Device Paths
345
346Paravirtual device backends are generally specified by their own
347directory within the XenStore hierarchy. Usually this is under
348~/backend/$TYPE/$DOMID/$DEVID.
349
350#### ~/backend/vbd/$DOMID/$DEVID/* []
351
352A virtual block device backend. Described by
353[xen/include/public/io/blkif.h][BLKIF]
354
355Uses the in-kernel blkback driver.
356
357#### ~/backend/qdisk/$DOMID/$DEVID/* []
358
359A virtual block device backend. Described by
360[xen/include/public/io/blkif.h][BLKIF]
361
362Uses the qemu based disk backend.
363
364#### ~/backend/tap/$DOMID/$DEVID/* []
365
366A virtual block device backend. Described by
367[xen/include/public/io/blkif.h][BLKIF]
368
369Uses the in-kernel blktap (v1) disk backend (deprecated).
370
371#### ~/backend/vfb/$DOMID/$DEVID/* []
372
373A virtual framebuffer backend. Described by
374[xen/include/public/io/fbif.h][FBIF]
375
376#### ~/backend/vkbd/$DOMID/$DEVID/* []
377
378A virtual keyboard device backend. Described by
379[xen/include/public/io/kbdif.h][KBDIF]
380
381#### ~/backend/vif/$DOMID/$DEVID/* []
382
383A virtual network device backend. Described by
384[xen/include/public/io/netif.h][NETIF]
385
386#### ~/backend/vscsi/$DOMID/$DEVID/* []
387
388A PV SCSI backend.
389
390#### ~/backend/vusb/$DOMID/$DEVID/* []
391
392A PV USB backend. Described by
393[xen/include/public/io/usbif.h][USBIF]
394
395#### ~/backend/pvcalls/$DOMID/$DEVID/* []
396
397A PVCalls backend. Described in [docs/misc/pvcalls.markdown][PVCALLS].
398
399#### ~/backend/console/$DOMID/$DEVID/* []
400
401A PV console backend. Described in [console.txt](console.txt)
402
403#### ~/backend/qusb/$DOMID/$DEVID/* []
404
405A PV USB device backend. Described by
406[xen/include/public/io/usbif.h][USBIF]
407
408Uses the qemu based USB backend.
409
410#### ~/device-model/$DOMID/* [INTERNAL]
411
412Information relating to device models running in the domain. $DOMID is
413the target domain of the device model.
414
415#### ~/libxl/disable_udev = ("1"|"0") []
416
417Indicates whether device hotplug scripts in this domain should be run
418by udev ("0") or will be run by the toolstack directly ("1").
419
420### Platform Feature and Control Paths
421
422#### ~/control/sysrq = (""|COMMAND) [w]
423
424This is the PV SysRq control node. A toolstack can write a single character
425representing a magic SysRq key understood by the Linux kernel.  The guest
426acknowledges a request by writing the empty string back to the command node.
427
428This protocol is Linux only.
429
430#### ~/control/shutdown = (""|COMMAND) [w]
431
432This is the PV shutdown control node. A toolstack can write various
433commands here to cause various guest shutdown, reboot or suspend
434activities. The guest acknowledges a request by writing the empty
435string back to the command node.
436
437The precise protocol is not yet documented.
438
439#### ~/control/feature-poweroff = (""|"0"|"1") [w]
440#### ~/control/feature-reboot = (""|"0"|"1") [w]
441#### ~/control/feature-suspend = (""|"0"|"1") [w]
442
443These may be initialized to "" by the toolstack and may then be set
444to 0 or 1 by a guest to indicate whether it is capable or incapable,
445respectively, of responding to the corresponding command when written
446to ~/control/shutdown.
447A toolstack may then sample the feature- value at the point of issuing
448a PV control command and respond accordingly:
449
450"0" -> the frontend should not be expected to respond, so fail the
451       control operation
452"1" -> the frontend should be expected to respond, so wait for it to
453       do so and maybe fail the control operation after some reasonable
454       timeout.
455""  -> the frontend may or may not respond, so wait for it to do so and
456       then maybe try an alternative control mechanism after some
457       reasonable timeout.
458
459Since a toolstack may not initialize these paths, and the parent
460~/control path is read-only to a guest, a guest should not expect a
461write to succeed. If it fails the guest may log the failure but should
462continue to process the corresponding command when written to
463~/control/shutdown regardless.
464
465#### ~/control/feature-s3 = (""|"0"|"1") [w,HVM]
466#### ~/control/feature-s4 = (""|"0"|"1") [w,HVM]
467
468These purpose of these feature flags is identical to feature-poweroff,
469feature-reboot and feature-suspend above but concern triggering the
470S3 or S4 power states of HVM guests.
471A toolstack may create these values, but should not sample them unless
472the corresponding acpi_ feature flag is set in ~/platform.
473
474#### ~/control/platform-feature-multiprocessor-suspend = (0|1) []
475
476Indicates to the guest that this platform supports the multiprocessor
477suspend feature.
478
479#### ~/control/platform-feature-xs_reset_watches = (0|1) []
480
481Indicates to the guest that this platform supports the
482XS_RESET_WATCHES xenstore message. See
483[xen/include/public/io/xs_wire.h][XSWIRE] for the XenStore wire
484protocol definition.
485
486#### ~/control/laptop-slate-mode = (""|"laptop"|"slate") [w]
487
488This is the PV laptop/slate mode control node. If the toolstack has
489provisioned a guest with the ACPI laptop/slate mode device then it
490can write the desired mode here to cause the guest to switch modes if
491necessary. The guest acknowledges a request by writing the empty
492string back to the control node.
493
494#### ~/control/feature-laptop-slate-mode = (""|"0"|"1") [w]
495
496This may be initialized to "" by the toolstack and may then be set
497to 0 or 1 by a guest to indicate whether it is capable or incapable,
498respectively, of responding to a mode value written to
499~/control/laptop-slate-mode.
500
501### Domain Controlled Paths
502
503#### ~/data/* [w]
504
505A domain writable path. Available for arbitrary domain use.
506
507#### ~/drivers/$INDEX = DISTRIBUTION [w]
508
509A domain may write information about installed PV drivers using
510paths of this form.
511
512#### ~/feature/hotplug/vif = ("0"|"1") [w]
513#### ~/feature/hotplug/vbd = ("0"|"1") [w]
514
515By setting these paths to "1" a guest can indicate to a toolstack
516that it is capable of responding immediately to instantiation of,
517respectively, new vif by bringing online a new PV network device or
518a new vbd by bringing online a new PV block device.
519If the guest sets this path to "0" then it is indicating that it is
520definitely unable to respond immediately and hence the toolstack should
521defer instantiaton to the next VM start. However, if the path is absent
522then the toolstack may attempt the operation.
523
524#### ~/attr/vif/$DEVID/name = STRING [w]
525
526A domain may write its internal 'friendly' name for a network device
527using this path using UTF-8 encoding. A toolstack or UI may use this
528for display purposes. No particular meaning should be inferred from the
529name.
530
531#### ~/attr/vif/$DEVID/mac/$INDEX = MAC_ADDRESS [w]
532
533Paths of this form may be written by the guest to indicate MAC addresses
534it is currently using. These may be multicast or unicast addresses. For
535any of the paths the value of $INDEX is arbitrary.
536The values written are primarily for display purposes and must not be used
537for packet filtering or routing purposes.
538
539#### ~/attr/vif/$DEVID/ipv4/$INDEX = IPV4_ADDRESS [w]
540#### ~/attr/vif/$DEVID/ipv6/$INDEX = IPV6_ADDRESS [w]
541
542Paths of this form may be written by the guest to indicate IP addresses
543in use by the stack bound to the network frontend. For any of the paths
544the value of $INDEX is arbitrary.
545The values written are primarily for display purposes and must not be used
546for packet filtering or routing purposes. A toolstack may attempt to use an
547address written in one of these paths to, for example, establish a VNC
548session to the guest (although clearly some level of trust is placed
549in the value supplied by the guest in this case).
550
551#### ~/error [w]
552
553A domain writable path used by some PV drivers to pass error messages
554to the toolstack.
555
556### Paths private to the toolstack
557
558#### ~/device-model/$DOMID/state [w]
559
560Contains the status of the device models running on the domain.
561
562#### ~/device-model/$DOMID/backends/* [w]
563
564Backend types the device model is supporting. Each entry below backends
565is a directory which may contain further nodes specific to the backend
566type. The name of each backend directory is the same as the backend type
567(e.g. "qdisk").
568
569#### ~/libxl/$DOMID/qdisk-backend-pid [w]
570
571Contains the PIDs of the device models running on the domain.
572
573## Virtual Machine Paths
574
575The /vm/$UUID namespace is used by toolstacks to store various
576information relating to the domain which is not intended to be guest
577visible (hence they are all tagged [n,INTERNAL]).
578
579Several of the keys here are not well defined and/or not well located
580and are liable to be replaced with more fully defined paths in the
581future.
582
583### /vm/$UUID/uuid = UUID [n,INTERNAL]
584
585Value is the same UUID as the path.
586
587### /vm/$UUID/name = STRING [n,INTERNAL]
588
589The domain's name.
590
591### /vm/$UUID/image/* [n,INTERNAL]
592
593Various information relating to the domain builder used for this guest.
594
595### /vm/$UUID/start_time = INTEGER "." INTEGER [n,INTERNAL]
596
597The time which the guest was started in SECONDS.MICROSECONDS format
598
599### /vm/$UUID/rtc/timeoffset = ""|INTEGER [n,HVM,INTERNAL]
600
601The guest's virtual time offset from UTC in seconds.
602
603## Platform-Level paths
604
605### libxl Specific Paths
606
607#### /libxl/$DOMID/device/$KIND/$DEVID
608
609Created by libxl for every frontend/backend pair created for $DOMID.
610Used by libxl for enumeration and management of the device.
611
612#### /libxl/$DOMID/device/$KIND/$DEVID/frontend
613
614Path in xenstore to the frontend, normally
615/local/domain/$DOMID/device/$KIND/$DEVID
616
617#### /libxl/$DOMID/device/$KIND/$DEVID/backend
618
619Path in xenstore to the backend, normally
620/local/domain/$BACKEND_DOMID/backend/$KIND/$DOMID/$DEVID
621
622#### /libxl/$DOMID/device/$KIND/$DEVID/$NODE
623
624Trustworthy copy of /local/domain/$DOMID/backend/$KIND/$DEVID/$NODE.
625
626#### /libxl/$DOMID/dm-version ("qemu_xen"|"qemu_xen_traditional") = [n,INTERNAL]
627
628The device model version for a domain.
629
630#### /libxl/$DOMID/remus/netbuf/$DEVID/ifb = STRING [n,INTERNAL]
631
632ifb device used by Remus to buffer network output from the associated vif.
633
634### xenstored specific paths
635
636The /tool/xenstored namespace is created by the xenstore daemon or domain
637for the toolstack to obtain e.g. the domain id of a xenstore domain.
638
639#### /tool/xenstored/domid = INTEGER [n,INTERNAL]
640
641Domain Id of the xenstore domain in case xenstore is provided via a
642domain instead of a daemon in dom0.
643
644[BLKIF]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,io,blkif.h.html
645[FBIF]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,io,fbif.h.html
646[HVMPARAMS]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,hvm,params.h.html
647[KBDIF]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,io,kbdif.h.html
648[LIBXLMEM]: https://xenbits.xen.org/docs/unstable/misc/libxl_memory.txt
649[NETIF]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,io,netif.h.html
650[SCSIIF]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,io,vscsiif.h.html
651[SI]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,xen.h.html#Struct_start_info
652[USBIF]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,io,usbif.h.html
653[VCPU]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,vcpu.h.html
654[XSWIRE]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,io,xs_wire.h.html
655