Files
xen/docs/misc/hypfs-paths.pandoc
T
Andrew Cooper d9fcdb0c7a docs/hypfs: Adjust the hypfs layout example
The controls for cpu-bugs were ultimately not taken.  As the paths are
documented fully below, pick only a small subset for the example.  Include
cpupool/ as it exists now.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
2026-03-30 15:48:13 +01:00

179 lines
5.6 KiB
Plaintext

# Xenhypfs Paths
This document attempts to define all the paths which are available
in the Xen hypervisor file system (hypfs).
The hypervisor file system can be accessed via the xenhypfs tool.
The availability of the hypervisor file system depends on the hypervisor
config option CONFIG_HYPFS, which is on per default.
## Notation
The hypervisor file system is similar to the Linux kernel's sysfs.
In this document directories are always specified with a trailing "/".
The following notation conventions apply:
DIRECTORY/
PATH = VALUES [TAGS]
The first syntax defines a directory. It normally contains related
entries and the general scope of the directory is described.
The second syntax defines a file entry containing values which are
either set by the hypervisor or, if the file is writable, can be set
by the user.
PATH can contain simple regex constructs following the Perl compatible
regexp syntax described in pcre(3) or perlre(1).
A hypervisor file system entry name can be any 0-delimited byte string
not containing any '/' character. The names "." and ".." are reserved
for file system internal use.
VALUES are strings and can take the following forms (note that this represents
only the syntax used in this document):
* STRING -- an arbitrary 0-delimited byte string.
* INTEGER -- An integer, in decimal representation unless otherwise
noted.
* "a literal string" -- literal strings are contained within quotes.
* (VALUE | VALUE | ... ) -- a set of alternatives. Alternatives are
separated by a "|" and all the alternatives are enclosed in "(" and
")".
* {VALUE, VALUE, ... } -- a list of possible values separated by "," and
enclosed in "{" and "}".
Additional TAGS may follow as a comma separated set of the following
tags enclosed in square brackets.
* w -- Path is writable by the user. This capability is usually
limited to the control domain (e.g. dom0).
* ARM | ARM32 | ARM64 | X86: the path is available for the respective
architecture only.
* PV -- Path is valid for PV capable hypervisors only.
* HVM -- Path is valid for HVM capable hypervisors only.
* CONFIG_* -- Path is valid only in case the hypervisor was built with
the respective config option.
So an entry could look like this:
/cpu-bugs/active-pv/xpti = ("No"|{"dom0", "domU", "PCID-on"}) [w,X86,PV]
Possible values would be "No" or a list of "dom0", "domU", and "PCID-on" with
the list elements separated by spaces, e.g. "dom0 PCID-on".
The entry would be writable and it would exist on X86 only and only if the
hypervisor is configured to support PV guests.
# Stability
Path *presence* is not stable, but path *meaning* is always stable: if a tool
you write finds a path present, it can rely on behavior in future versions of
the hypervisors, and in different configurations. Specifically:
1. Conditions under which paths are used may be extended, restricted, or
removed. For example, a path that's always available only on ARM systems
may become available on x86; or a path available on both systems may be
restricted to only appearing on ARM systems. Paths may also disappear
entirely.
2. However, the meaning of a path will never change. If a path is present,
it will always have exactly the meaning that it always had. In order to
maintain this, removed paths should be retained with the tag [REMOVED].
The path may be restored *only* if the restored version of the path is
compatible with the previous functionality.
## Example
A populated Xen hypervisor file system might look like the following example:
/
buildinfo/ directory containing build-time data
config contents of .config file used to build Xen
cpupool/ directory containing CPU Pool data
0/ directory for cpupool 0
sched-gran "cpu", "core" or "socket"
params/ directory with hypervisor parameter values
loglvl "none", "error", "warning", "info", "all"
## General Paths
#### /
The root of the hypervisor file system.
#### /buildinfo/
A directory containing static information generated while building the
hypervisor.
#### /buildinfo/changeset = STRING
Git commit of the hypervisor.
#### /buildinfo/compileinfo/
A directory containing information about compilation of Xen.
#### /buildinfo/compileinfo/compile_by = STRING
Information who compiled the hypervisor.
#### /buildinfo/compileinfo/compile_date = STRING
Date of the hypervisor compilation.
#### /buildinfo/compileinfo/compile_domain = STRING
Information about the compile domain.
#### /buildinfo/compileinfo/compiler = STRING
The compiler used to build Xen.
#### /buildinfo/config = STRING [CONFIG_HYPFS_CONFIG]
The contents of the `xen/.config` file at the time of the hypervisor build.
#### /buildinfo/version/
A directory containing version information of the hypervisor.
#### /buildinfo/version/extra = STRING
Extra version information.
#### /buildinfo/version/major = INTEGER
The major version of Xen.
#### /buildinfo/version/minor = INTEGER
The minor version of Xen.
#### /cpupool/
A directory of all current cpupools.
#### /cpupool/*/
The individual cpupools. Each entry is a directory with the name being the
cpupool-id (e.g. /cpupool/0/).
#### /cpupool/*/sched-gran = ("cpu" | "core" | "socket") [w]
The scheduling granularity of a cpupool.
Writing a value is allowed only for cpupools with no cpu assigned and if the
architecture is supporting different scheduling granularities.
#### /params/
A directory of runtime parameters.
#### /params/* [w]
The individual parameters. The description of the different parameters can be
found in `docs/misc/xen-command-line.pandoc`.