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