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
273#### ~/platform/tpm_version = INTEGER [HVM,INTERNAL]
274
275The TPM version to be probed for.
276
277A value of 1 indicates to probe for TPM 1.2, whereas a value of 2
278indicates that a TPM 2.0 using CRB should be probed.
279A value of 0 or an invalid value will result in no TPM being probed.
280If unset, a default of 1 is assumed.
281
282### Frontend device paths
283
284Paravirtual device frontends are generally specified by their own
285directory within the XenStore hierarchy. Usually this is under
286~/device/$TYPE/$DEVID although there are exceptions, e.g. ~/console
287for the first PV console. The top level ~/device path itself is normally
288read-only to the guest. However it may writable if the
289'xend_suspend_evtchn_compat' guest configuration option is enabled.
290
291#### ~/device/vbd/$DEVID/* []
292
293A virtual block device frontend. Described by
294[xen/include/public/io/blkif.h][BLKIF]
295
296#### ~/device/vfb/$DEVID/* []
297
298A virtual framebuffer frontend. Described by
299[xen/include/public/io/fbif.h][FBIF]
300
301#### ~/device/vkbd/$DEVID/* []
302
303A virtual keyboard device frontend. Described by
304[xen/include/public/io/kbdif.h][KBDIF]
305
306#### ~/device/vif/$DEVID/* []
307
308A virtual network device frontend. Described by
309[xen/include/public/io/netif.h][NETIF]
310
311NOTE: ~/device/vif/$DEVID/mtu can be used to inform the frontend of an
312      increased MTU. (The default MTU is 1500 octets).
313
314#### ~/device/vscsi/$DEVID/* []
315
316A virtual scsi device frontend. Described by
317[xen/include/public/io/vscsiif.h][SCSIIF]
318
319#### ~/device/vusb/$DEVID/* []
320
321A virtual usb device frontend. Described by
322[xen/include/public/io/usbif.h][USBIF]
323
324#### ~/device/pvcalls/$DEVID/* []
325
326Paravirtualized POSIX function calls frontend. Described by
327[docs/misc/pvcalls.markdown][PVCALLS]
328
329#### ~/console/* []
330
331The primary PV console device. Described in [console.txt](console.txt)
332
333#### ~/device/console/$DEVID/* []
334
335A secondary PV console device. Described in [console.txt](console.txt)
336
337#### ~/serial/$DEVID/* [HVM]
338
339An emulated serial device. Described in [console.txt](console.txt)
340
341#### ~/store/port = EVTCHN [DEPRECATED]
342
343The event channel used by the domain's connection to XenStore.
344
345This path is deprecated since the same information is provided via the
346[start_info][SI] for PV guests and as an [HVM param][HVMPARAMS] for
347HVM guests. There is an obvious chicken and egg problem with
348extracting this value from xenstore in order to setup the xenstore
349communication ring.
350
351#### ~/store/ring-ref = GNTREF [DEPRECATED]
352
353The grant reference of the domain's XenStore ring.
354
355As with ~/store/port this path is deprecated.
356
357### Backend Device Paths
358
359Paravirtual device backends are generally specified by their own
360directory within the XenStore hierarchy. Usually this is under
361~/backend/$TYPE/$DOMID/$DEVID.
362
363#### ~/backend/vbd/$DOMID/$DEVID/* []
364
365A virtual block device backend. Described by
366[xen/include/public/io/blkif.h][BLKIF]
367
368Uses the in-kernel blkback driver.
369
370#### ~/backend/qdisk/$DOMID/$DEVID/* []
371
372A virtual block device backend. Described by
373[xen/include/public/io/blkif.h][BLKIF]
374
375Uses the qemu based disk backend.
376
377#### ~/backend/tap/$DOMID/$DEVID/* []
378
379A virtual block device backend. Described by
380[xen/include/public/io/blkif.h][BLKIF]
381
382Uses the in-kernel blktap (v1) disk backend (deprecated).
383
384#### ~/backend/vfb/$DOMID/$DEVID/* []
385
386A virtual framebuffer backend. Described by
387[xen/include/public/io/fbif.h][FBIF]
388
389#### ~/backend/vkbd/$DOMID/$DEVID/* []
390
391A virtual keyboard device backend. Described by
392[xen/include/public/io/kbdif.h][KBDIF]
393
394#### ~/backend/vif/$DOMID/$DEVID/* []
395
396A virtual network device backend. Described by
397[xen/include/public/io/netif.h][NETIF]
398
399#### ~/backend/vscsi/$DOMID/$DEVID/* []
400
401A PV SCSI backend.
402
403#### ~/backend/vusb/$DOMID/$DEVID/* []
404
405A PV USB backend. Described by
406[xen/include/public/io/usbif.h][USBIF]
407
408#### ~/backend/pvcalls/$DOMID/$DEVID/* []
409
410A PVCalls backend. Described in [docs/misc/pvcalls.markdown][PVCALLS].
411
412#### ~/backend/console/$DOMID/$DEVID/* []
413
414A PV console backend. Described in [console.txt](console.txt)
415
416#### ~/backend/qusb/$DOMID/$DEVID/* []
417
418A PV USB device backend. Described by
419[xen/include/public/io/usbif.h][USBIF]
420
421Uses the qemu based USB backend.
422
423#### ~/device-model/$DOMID/* [INTERNAL]
424
425Information relating to device models running in the domain. $DOMID is
426the target domain of the device model.
427
428#### ~/libxl/disable_udev = ("1"|"0") []
429
430Indicates whether device hotplug scripts in this domain should be run
431by udev ("0") or will be run by the toolstack directly ("1").
432
433### Platform Feature and Control Paths
434
435#### ~/control/sysrq = (""|COMMAND) [w]
436
437This is the PV SysRq control node. A toolstack can write a single character
438representing a magic SysRq key understood by the Linux kernel.  The guest
439acknowledges a request by writing the empty string back to the command node.
440
441This protocol is Linux only.
442
443#### ~/control/shutdown = (""|COMMAND) [w]
444
445This is the PV shutdown control node. A toolstack can write various
446commands here to cause various guest shutdown, reboot or suspend
447activities. The guest acknowledges a request by writing the empty
448string back to the command node.
449
450The precise protocol is not yet documented.
451
452#### ~/control/feature-poweroff = (""|"0"|"1") [w]
453#### ~/control/feature-reboot = (""|"0"|"1") [w]
454#### ~/control/feature-suspend = (""|"0"|"1") [w]
455
456These may be initialized to "" by the toolstack and may then be set
457to 0 or 1 by a guest to indicate whether it is capable of responding
458to the corresponding command when written to ~/control/shutdown.
459A toolstack may then sample the feature- value at the point of issuing
460a PV control command and respond accordingly:
461
462"0" -> the frontend should not be expected to respond, so fail the
463       control operation
464"1" -> the frontend should be expected to respond, so wait for it to
465       do so and maybe fail the control operation after some reasonable
466       timeout.
467""  -> the frontend may or may not respond, so wait for it to do so and
468       then maybe try an alternative control mechanism after some
469       reasonable timeout.
470
471Since a toolstack may not initialize these paths, and the parent
472~/control path is read-only to a guest, a guest should not expect a
473write to succeed. If it fails the guest may log the failure but should
474continue to process the corresponding command when written to
475~/control/shutdown regardless.
476
477#### ~/control/feature-s3 = (""|"0"|"1") [w,HVM]
478#### ~/control/feature-s4 = (""|"0"|"1") [w,HVM]
479
480These purpose of these feature flags is identical to feature-poweroff,
481feature-reboot and feature-suspend above but concern triggering the
482S3 or S4 power states of HVM guests.
483A toolstack may create these values, but should not sample them unless
484the corresponding acpi_ feature flag is set in ~/platform.
485
486#### ~/control/platform-feature-multiprocessor-suspend = (0|1) []
487
488Indicates to the guest that this platform supports the multiprocessor
489suspend feature.
490
491#### ~/control/platform-feature-xs_reset_watches = (0|1) []
492
493Indicates to the guest that this platform supports the
494XS_RESET_WATCHES xenstore message. See
495[xen/include/public/io/xs_wire.h][XSWIRE] for the XenStore wire
496protocol definition.
497
498#### ~/control/laptop-slate-mode = (""|"laptop"|"slate") [w]
499
500This is the PV laptop/slate mode control node. If the toolstack has
501provisioned a guest with the ACPI laptop/slate mode device then it
502can write the desired mode here to cause the guest to switch modes if
503necessary. The guest acknowledges a request by writing the empty
504string back to the control node.
505
506#### ~/control/feature-laptop-slate-mode = (""|"0"|"1") [w]
507
508This may be initialized to "" by the toolstack and may then be set
509to 0 or 1 by a guest to indicate whether it is capable of responding
510to a mode value written to ~/control/laptop-slate-mode.
511
512### Domain Controlled Paths
513
514#### ~/data/* [w]
515
516A domain writable path. Available for arbitrary domain use.
517
518#### ~/drivers/$INDEX = DISTRIBUTION [w]
519
520A domain may write information about installed PV drivers using
521paths of this form.
522
523#### ~/feature/hotplug/vif = ("0"|"1") [w]
524#### ~/feature/hotplug/vbd = ("0"|"1") [w]
525
526By setting these paths to "1" a guest can indicate to a toolstack
527that it is capable of responding immediately to instantiation of,
528respectively, new vif by bringing online a new PV network device or
529a new vbd by bringing online a new PV block device.
530If the guest sets this path to "0" then it is indicating that it is
531definitely unable to respond immediately and hence the toolstack should
532defer instantiaton to the next VM start. However, if the path is absent
533then the toolstack may attempt the operation.
534
535#### ~/attr/vif/$DEVID/name = STRING [w]
536
537A domain may write its internal 'friendly' name for a network device
538using this path using UTF-8 encoding. A toolstack or UI may use this
539for display purposes. No particular meaning should be inferred from the
540name.
541
542#### ~/attr/vif/$DEVID/mac/$INDEX = MAC_ADDRESS [w]
543
544Paths of this form may be written by the guest to indicate MAC addresses
545it is currently using. These may be multicast or unicast addresses. For
546any of the paths the value of $INDEX is arbitrary.
547The values written are primarily for display purposes and must not be used
548for packet filtering or routing purposes.
549
550#### ~/attr/vif/$DEVID/ipv4/$INDEX = IPV4_ADDRESS [w]
551#### ~/attr/vif/$DEVID/ipv6/$INDEX = IPV6_ADDRESS [w]
552
553Paths of this form may be written by the guest to indicate IP addresses
554in use by the stack bound to the network frontend. For any of the paths
555the value of $INDEX is arbitrary.
556The values written are primarily for display purposes and must not be used
557for packet filtering or routing purposes. A toolstack may attempt to use an
558address written in one of these paths to, for example, establish a VNC
559session to the guest (although clearly some level of trust is placed
560in the value supplied by the guest in this case).
561
562#### ~/error [w]
563
564A domain writable path used by some PV drivers to pass error messages
565to the toolstack.
566
567### Paths private to the toolstack
568
569#### ~/device-model/$DOMID/state [w]
570
571Contains the status of the device models running on the domain.
572
573#### ~/device-model/$DOMID/backends/* [w]
574
575Backend types the device model is supporting. Each entry below backends
576is a directory which may contain further nodes specific to the backend
577type. The name of each backend directory is the same as the backend type
578(e.g. "qdisk").
579
580#### ~/libxl/$DOMID/qdisk-backend-pid [w]
581
582Contains the PIDs of the device models running on the domain.
583
584## Virtual Machine Paths
585
586The /vm/$UUID namespace is used by toolstacks to store various
587information relating to the domain which is not intended to be guest
588visible (hence they are all tagged [n,INTERNAL]).
589
590Several of the keys here are not well defined and/or not well located
591and are liable to be replaced with more fully defined paths in the
592future.
593
594### /vm/$UUID/uuid = UUID [n,INTERNAL]
595
596Value is the same UUID as the path.
597
598### /vm/$UUID/name = STRING [n,INTERNAL]
599
600The domain's name.
601
602### /vm/$UUID/image/* [n,INTERNAL]
603
604Various information relating to the domain builder used for this guest.
605
606### /vm/$UUID/start_time = INTEGER "." INTEGER [n,INTERNAL]
607
608The time which the guest was started in SECONDS.MICROSECONDS format
609
610### /vm/$UUID/rtc/timeoffset = ""|INTEGER [n,HVM,INTERNAL]
611
612The guest's virtual time offset from UTC in seconds.
613
614## Platform-Level paths
615
616### libxl Specific Paths
617
618#### /libxl/$DOMID/device/$KIND/$DEVID
619
620Created by libxl for every frontend/backend pair created for $DOMID.
621Used by libxl for enumeration and management of the device.
622
623#### /libxl/$DOMID/device/$KIND/$DEVID/frontend
624
625Path in xenstore to the frontend, normally
626/local/domain/$DOMID/device/$KIND/$DEVID
627
628#### /libxl/$DOMID/device/$KIND/$DEVID/backend
629
630Path in xenstore to the backend, normally
631/local/domain/$BACKEND_DOMID/backend/$KIND/$DOMID/$DEVID
632
633#### /libxl/$DOMID/device/$KIND/$DEVID/$NODE
634
635Trustworthy copy of /local/domain/$DOMID/backend/$KIND/$DEVID/$NODE.
636
637#### /libxl/$DOMID/dm-version ("qemu_xen"|"qemu_xen_traditional") = [n,INTERNAL]
638
639The device model version for a domain.
640
641#### /libxl/$DOMID/remus/netbuf/$DEVID/ifb = STRING [n,INTERNAL]
642
643ifb device used by Remus to buffer network output from the associated vif.
644
645### xenstored specific paths
646
647The /tool/xenstored namespace is created by the xenstore daemon or domain
648for the toolstack to obtain e.g. the domain id of a xenstore domain.
649
650#### /tool/xenstored/domid = INTEGER [n,INTERNAL]
651
652Domain Id of the xenstore domain in case xenstore is provided via a
653domain instead of a daemon in dom0.
654
655[BLKIF]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,io,blkif.h.html
656[FBIF]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,io,fbif.h.html
657[HVMPARAMS]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,hvm,params.h.html
658[KBDIF]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,io,kbdif.h.html
659[LIBXLMEM]: https://xenbits.xen.org/docs/unstable/misc/libxl_memory.txt
660[NETIF]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,io,netif.h.html
661[SCSIIF]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,io,vscsiif.h.html
662[SI]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,xen.h.html#Struct_start_info
663[USBIF]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,io,usbif.h.html
664[VCPU]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,vcpu.h.html
665[XSWIRE]: https://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,io,xs_wire.h.html
666