libvirt/docs/schemas/capability.rng

528 lines
12 KiB
Plaintext
Raw Normal View History

<?xml version="1.0"?>
<!-- A Relax NG schema for the libvirt capabilities XML format -->
<grammar xmlns="http://relaxng.org/ns/structure/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<include href="basictypes.rng"/>
<include href="cputypes.rng"/>
<start>
<ref name="capabilities"/>
</start>
<define name="capabilities">
<element name="capabilities">
<ref name="hostcaps"/>
<zeroOrMore>
<ref name="guestcaps"/>
</zeroOrMore>
</element>
</define>
<define name="hostcaps">
<element name="host">
<optional>
<element name="uuid">
<ref name="UUID"/>
</element>
</optional>
<ref name="hostcpu"/>
<optional>
<ref name="power_management"/>
</optional>
<optional>
<ref name="iommu_support"/>
</optional>
<optional>
<ref name="migration"/>
</optional>
<optional>
<ref name="topology"/>
</optional>
<optional>
<ref name="cache"/>
</optional>
<optional>
<ref name="memory_bandwidth"/>
</optional>
<zeroOrMore>
<ref name="secmodel"/>
</zeroOrMore>
</element>
</define>
<define name="secmodel">
<element name="secmodel">
<interleave>
<element name="model">
<text/>
</element>
<element name="doi">
<text/>
</element>
<zeroOrMore>
<element name="baselabel">
<attribute name="type">
<text/>
</attribute>
<text/>
</element>
</zeroOrMore>
</interleave>
</element>
</define>
<define name="power_management">
<element name="power_management">
<interleave>
<optional>
<element name="suspend_mem">
<empty/>
</element>
</optional>
<optional>
<element name="suspend_disk">
<empty/>
</element>
</optional>
<optional>
<element name="suspend_hybrid">
<empty/>
</element>
</optional>
</interleave>
</element>
</define>
<define name="iommu_support">
<element name="iommu">
<optional>
<attribute name="support">
<ref name="virYesNo"/>
</attribute>
</optional>
</element>
</define>
<define name="migration">
<element name="migration_features">
<optional>
<element name="live">
<empty/>
</element>
</optional>
<optional>
<element name="uri_transports">
<oneOrMore>
<element name="uri_transport">
<choice>
<value>vpxmigr</value>
<value>tcp</value>
<value>rdma</value>
<value>vzmigr</value>
</choice>
</element>
</oneOrMore>
</element>
</optional>
</element>
</define>
<define name="topology">
<element name="topology">
<element name="cells">
<attribute name="num">
<ref name="unsignedInt"/>
</attribute>
<oneOrMore>
<ref name="cell"/>
</oneOrMore>
</element>
capabilities: Expose NUMA interconnects Links between NUMA nodes can have different latencies and bandwidths. This info is newly defined in ACPI 6.2 under Heterogeneous Memory Attribute Table (HMAT) table. Linux kernel learned how to report these values under sysfs and thus we can expose them in our capabilities XML. The sysfs interface is documented in kernel's Documentation/admin-guide/mm/numaperf.rst. Long story short, two nodes can be in initiator-target relationship. A node can be initiator if it has a CPU or a device that's capable of initiating memory transfer. Therefore a node that has just memory can only be target. An initiator-target link can then have any combination of {bandwidth, latency} - {access, read, write} attribute (6 in total). However, the standard says access is applicable iff read and write values are the same. Therefore, we really have just four combinations of attributes: bandwidth-read, bandwidth-write, latency-read, latency-write. This is the combination that kernel reports anyway. Then, under /sys/system/devices/node/nodeX/acccessN/initiators we find values for those 4 attributes and also symlinks named "nodeN" which then represent initiators to nodeX. For instance: /sys/system/node/node1/access1/initiators/node0 -> ../../node0 /sys/system/node/node1/access1/initiators/read_bandwidth /sys/system/node/node1/access1/initiators/read_latency /sys/system/node/node1/access1/initiators/write_bandwidth /sys/system/node/node1/access1/initiators/write_latency This means that node0 is initiator and node1 is target and values of the interconnect can be read. In theory, there can be separate links to memory side caches too (e.g. one link from node X to node Y's main memory, another from node X to node Y's L1 cache, another one to L2 cache and so on). But sysfs does not express this relationship just yet. The "accessN" means either "access0" or "access1". The difference is that while the former expresses the best interconnect between two nodes including CPUS and I/O devices (such as GPUs and NICs), the latter includes only CPUs and thus is what we need. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1786309 Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2021-05-17 11:36:34 +00:00
<optional>
<ref name="numaInterconnects"/>
</optional>
</element>
</define>
<define name="cell">
<element name="cell">
<attribute name="id">
<ref name="unsignedInt"/>
</attribute>
<optional>
<ref name="memory"/>
</optional>
<zeroOrMore>
<ref name="pagesNuma"/>
</zeroOrMore>
<optional>
<element name="distances">
<oneOrMore>
<ref name="numaDistance"/>
</oneOrMore>
</element>
</optional>
<zeroOrMore>
<ref name="numaCache"/>
</zeroOrMore>
<optional>
<element name="cpus">
<attribute name="num">
<ref name="unsignedInt"/>
</attribute>
<zeroOrMore>
<ref name="cpu"/>
</zeroOrMore>
</element>
</optional>
</element>
</define>
<define name="memory">
<element name="memory">
<ref name="scaledInteger"/>
</element>
</define>
<define name="cpu">
<element name="cpu">
<attribute name="id">
<ref name="unsignedInt"/>
</attribute>
schemas: Add schemas for more CPU topology information in the caps XML This patch adds RNG schemas for adding more information in the topology output of the NUMA section in the capabilities XML. The added elements are designed to provide more information about the placement and topology of the processors in the system to management applications. A demonstration of supported XML added by this patch: <capabilities> <host> <topology> <cells num='3'> <cell id='0'> <cpus num='4'> <!-- this is node with Hyperthreading --> <cpu id='0' socket_id='0' core_id='0' siblings='0-1'/> <cpu id='1' socket_id='0' core_id='0' siblings='0-1'/> <cpu id='2' socket_id='0' core_id='1' siblings='2-3'/> <cpu id='3' socket_id='0' core_id='1' siblings='2-3'/> </cpus> </cell> <cell id='1'> <cpus num='4'> <!-- this is node with modules (Bulldozer) --> <cpu id='4' socket_id='0' core_id='2' siblings='4-5'/> <cpu id='5' socket_id='0' core_id='3' siblings='4-5'/> <cpu id='6' socket_id='0' core_id='4' siblings='6-7'/> <cpu id='7' socket_id='0' core_id='5' siblings='6-7'/> </cpus> </cell> <cell id='2'> <cpus num='4'> <!-- this is a normal multi-core node --> <cpu id='8' socket_id='1' core_id='0' siblings='8'/> <cpu id='9' socket_id='1' core_id='1' siblings='9'/> <cpu id='10' socket_id='1' core_id='2' siblings='10'/> <cpu id='11' socket_id='1' core_id='3' siblings='11'/> </cpus> </cell> </cells> </topology> </host> </capabilities> The socket_id field represents identification of the physical socket the CPU is plugged in. This ID may not be identical to the physical socket ID reported by the kernel. The core_id identifies a core within a socket. Also this field may not accurately represent physical ID's. The core_id is guaranteed to be unique within a cell and a socket. There may be duplicates between sockets. Only cores sharing core_id within one cell and one socket can be considered as threads. Cores sharing core_id within sparate cells are distinct cores. The siblings field is a list of CPU id's the cpu id's the CPU is sibling with - thus a thread. The list is in the cpuset format.
2013-01-18 18:30:00 +00:00
<optional>
<attribute name="socket_id">
<ref name="unsignedInt"/>
schemas: Add schemas for more CPU topology information in the caps XML This patch adds RNG schemas for adding more information in the topology output of the NUMA section in the capabilities XML. The added elements are designed to provide more information about the placement and topology of the processors in the system to management applications. A demonstration of supported XML added by this patch: <capabilities> <host> <topology> <cells num='3'> <cell id='0'> <cpus num='4'> <!-- this is node with Hyperthreading --> <cpu id='0' socket_id='0' core_id='0' siblings='0-1'/> <cpu id='1' socket_id='0' core_id='0' siblings='0-1'/> <cpu id='2' socket_id='0' core_id='1' siblings='2-3'/> <cpu id='3' socket_id='0' core_id='1' siblings='2-3'/> </cpus> </cell> <cell id='1'> <cpus num='4'> <!-- this is node with modules (Bulldozer) --> <cpu id='4' socket_id='0' core_id='2' siblings='4-5'/> <cpu id='5' socket_id='0' core_id='3' siblings='4-5'/> <cpu id='6' socket_id='0' core_id='4' siblings='6-7'/> <cpu id='7' socket_id='0' core_id='5' siblings='6-7'/> </cpus> </cell> <cell id='2'> <cpus num='4'> <!-- this is a normal multi-core node --> <cpu id='8' socket_id='1' core_id='0' siblings='8'/> <cpu id='9' socket_id='1' core_id='1' siblings='9'/> <cpu id='10' socket_id='1' core_id='2' siblings='10'/> <cpu id='11' socket_id='1' core_id='3' siblings='11'/> </cpus> </cell> </cells> </topology> </host> </capabilities> The socket_id field represents identification of the physical socket the CPU is plugged in. This ID may not be identical to the physical socket ID reported by the kernel. The core_id identifies a core within a socket. Also this field may not accurately represent physical ID's. The core_id is guaranteed to be unique within a cell and a socket. There may be duplicates between sockets. Only cores sharing core_id within one cell and one socket can be considered as threads. Cores sharing core_id within sparate cells are distinct cores. The siblings field is a list of CPU id's the cpu id's the CPU is sibling with - thus a thread. The list is in the cpuset format.
2013-01-18 18:30:00 +00:00
</attribute>
<attribute name="die_id">
<ref name="unsignedInt"/>
</attribute>
<attribute name="core_id">
<ref name="unsignedInt"/>
schemas: Add schemas for more CPU topology information in the caps XML This patch adds RNG schemas for adding more information in the topology output of the NUMA section in the capabilities XML. The added elements are designed to provide more information about the placement and topology of the processors in the system to management applications. A demonstration of supported XML added by this patch: <capabilities> <host> <topology> <cells num='3'> <cell id='0'> <cpus num='4'> <!-- this is node with Hyperthreading --> <cpu id='0' socket_id='0' core_id='0' siblings='0-1'/> <cpu id='1' socket_id='0' core_id='0' siblings='0-1'/> <cpu id='2' socket_id='0' core_id='1' siblings='2-3'/> <cpu id='3' socket_id='0' core_id='1' siblings='2-3'/> </cpus> </cell> <cell id='1'> <cpus num='4'> <!-- this is node with modules (Bulldozer) --> <cpu id='4' socket_id='0' core_id='2' siblings='4-5'/> <cpu id='5' socket_id='0' core_id='3' siblings='4-5'/> <cpu id='6' socket_id='0' core_id='4' siblings='6-7'/> <cpu id='7' socket_id='0' core_id='5' siblings='6-7'/> </cpus> </cell> <cell id='2'> <cpus num='4'> <!-- this is a normal multi-core node --> <cpu id='8' socket_id='1' core_id='0' siblings='8'/> <cpu id='9' socket_id='1' core_id='1' siblings='9'/> <cpu id='10' socket_id='1' core_id='2' siblings='10'/> <cpu id='11' socket_id='1' core_id='3' siblings='11'/> </cpus> </cell> </cells> </topology> </host> </capabilities> The socket_id field represents identification of the physical socket the CPU is plugged in. This ID may not be identical to the physical socket ID reported by the kernel. The core_id identifies a core within a socket. Also this field may not accurately represent physical ID's. The core_id is guaranteed to be unique within a cell and a socket. There may be duplicates between sockets. Only cores sharing core_id within one cell and one socket can be considered as threads. Cores sharing core_id within sparate cells are distinct cores. The siblings field is a list of CPU id's the cpu id's the CPU is sibling with - thus a thread. The list is in the cpuset format.
2013-01-18 18:30:00 +00:00
</attribute>
<attribute name="siblings">
<ref name="cpuset"/>
schemas: Add schemas for more CPU topology information in the caps XML This patch adds RNG schemas for adding more information in the topology output of the NUMA section in the capabilities XML. The added elements are designed to provide more information about the placement and topology of the processors in the system to management applications. A demonstration of supported XML added by this patch: <capabilities> <host> <topology> <cells num='3'> <cell id='0'> <cpus num='4'> <!-- this is node with Hyperthreading --> <cpu id='0' socket_id='0' core_id='0' siblings='0-1'/> <cpu id='1' socket_id='0' core_id='0' siblings='0-1'/> <cpu id='2' socket_id='0' core_id='1' siblings='2-3'/> <cpu id='3' socket_id='0' core_id='1' siblings='2-3'/> </cpus> </cell> <cell id='1'> <cpus num='4'> <!-- this is node with modules (Bulldozer) --> <cpu id='4' socket_id='0' core_id='2' siblings='4-5'/> <cpu id='5' socket_id='0' core_id='3' siblings='4-5'/> <cpu id='6' socket_id='0' core_id='4' siblings='6-7'/> <cpu id='7' socket_id='0' core_id='5' siblings='6-7'/> </cpus> </cell> <cell id='2'> <cpus num='4'> <!-- this is a normal multi-core node --> <cpu id='8' socket_id='1' core_id='0' siblings='8'/> <cpu id='9' socket_id='1' core_id='1' siblings='9'/> <cpu id='10' socket_id='1' core_id='2' siblings='10'/> <cpu id='11' socket_id='1' core_id='3' siblings='11'/> </cpus> </cell> </cells> </topology> </host> </capabilities> The socket_id field represents identification of the physical socket the CPU is plugged in. This ID may not be identical to the physical socket ID reported by the kernel. The core_id identifies a core within a socket. Also this field may not accurately represent physical ID's. The core_id is guaranteed to be unique within a cell and a socket. There may be duplicates between sockets. Only cores sharing core_id within one cell and one socket can be considered as threads. Cores sharing core_id within sparate cells are distinct cores. The siblings field is a list of CPU id's the cpu id's the CPU is sibling with - thus a thread. The list is in the cpuset format.
2013-01-18 18:30:00 +00:00
</attribute>
</optional>
</element>
</define>
<define name="cache">
<element name="cache">
<oneOrMore>
<element name="bank">
<attribute name="id">
<ref name="unsignedInt"/>
</attribute>
<attribute name="level">
<ref name="unsignedInt"/>
</attribute>
<ref name="cacheType"/>
<attribute name="size">
<ref name="unsignedInt"/>
</attribute>
<attribute name="unit">
<ref name="unit"/>
</attribute>
<attribute name="cpus">
<ref name="cpuset"/>
</attribute>
<zeroOrMore>
<element name="control">
<attribute name="granularity">
<ref name="unsignedInt"/>
</attribute>
<optional>
<attribute name="min">
<ref name="unsignedInt"/>
</attribute>
</optional>
<attribute name="unit">
<ref name="unit"/>
</attribute>
<ref name="cacheType"/>
<attribute name="maxAllocs">
<ref name="unsignedInt"/>
</attribute>
</element>
</zeroOrMore>
</element>
</oneOrMore>
<optional>
<ref name="cpuMonitor"/>
</optional>
</element>
</define>
<define name="cacheType">
<attribute name="type">
<choice>
<value>both</value>
<value>code</value>
<value>data</value>
</choice>
</attribute>
</define>
<define name="memory_bandwidth">
<element name="memory_bandwidth">
<oneOrMore>
<element name="node">
<attribute name="id">
<ref name="unsignedInt"/>
</attribute>
<attribute name="cpus">
<ref name="cpuset"/>
</attribute>
<zeroOrMore>
<element name="control">
<attribute name="granularity">
<ref name="unsignedInt"/>
</attribute>
<optional>
<attribute name="min">
<ref name="unsignedInt"/>
</attribute>
</optional>
<attribute name="maxAllocs">
<ref name="unsignedInt"/>
</attribute>
</element>
</zeroOrMore>
</element>
</oneOrMore>
<optional>
<ref name="cpuMonitor"/>
</optional>
</element>
</define>
<define name="cpuMonitor">
<element name="monitor">
<optional>
<attribute name="level">
<ref name="unsignedInt"/>
</attribute>
<attribute name="reuseThreshold">
<ref name="unsignedInt"/>
</attribute>
</optional>
<attribute name="maxMonitors">
<ref name="unsignedInt"/>
</attribute>
<oneOrMore>
<element name="feature">
<attribute name="name">
<ref name="monitorFeature"/>
</attribute>
</element>
</oneOrMore>
</element>
</define>
<define name="monitorFeature">
<data type="string">
<param name="pattern">(llc_|mbm_)[a-zA-Z0-9\-_]+</param>
</data>
</define>
<define name="guestcaps">
<element name="guest">
<ref name="ostype"/>
<ref name="arch"/>
<optional>
<ref name="features"/>
</optional>
</element>
</define>
<define name="ostype">
<element name="os_type">
<choice>
<value>xen</value> <!-- Xen 3.0 pv -->
<value>linux</value> <!-- same as "xen" - meant to be legacy -->
<value>hvm</value> <!-- unmodified OS -->
<value>exe</value> <!-- For container based virt -->
<value>uml</value> <!-- user mode linux; NOT USED ANYMORE -->
</choice>
</element>
</define>
<define name="arch">
<element name="arch">
<attribute name="name">
<ref name="archnames"/>
</attribute>
<ref name="wordsize"/>
<optional>
<ref name="emulator"/>
</optional>
<optional>
<ref name="loader"/>
</optional>
<zeroOrMore>
<ref name="machine"/>
</zeroOrMore>
<oneOrMore>
<ref name="domain"/>
</oneOrMore>
</element>
</define>
<define name="emulator">
<element name="emulator">
<ref name="absFilePath"/>
</element>
</define>
<define name="loader">
<element name="loader">
<ref name="absFilePath"/>
</element>
</define>
<define name="wordsize">
<element name="wordsize">
<choice>
<value>31</value>
<value>32</value>
<value>64</value>
</choice>
</element>
</define>
<define name="machine">
<element name="machine">
<optional>
<attribute name="canonical">
<text/>
</attribute>
</optional>
<optional>
<attribute name="maxCpus">
<ref name="unsignedInt"/>
</attribute>
</optional>
<optional>
<attribute name="deprecated">
<choice>
<value>yes</value>
<value>no</value>
</choice>
</attribute>
</optional>
<text/>
</element>
</define>
<define name="domain">
<element name="domain">
<attribute name="type">
<choice>
<value>qemu</value>
<value>kqemu</value>
<value>kvm</value>
<value>xen</value>
<value>uml</value> <!-- NOT USED ANYMORE -->
<value>lxc</value>
<value>openvz</value>
<value>test</value>
</choice>
</attribute>
<optional>
<ref name="emulator"/>
</optional>
<zeroOrMore>
<ref name="machine"/>
</zeroOrMore>
</element>
</define>
<define name="features">
<element name="features">
<interleave>
<optional>
<element name="pae">
<empty/>
</element>
</optional>
<optional>
<element name="nonpae">
<empty/>
</element>
</optional>
<optional>
<element name="ia64_be">
<empty/>
</element>
</optional>
<optional>
<element name="acpi">
<ref name="featuretoggle"/>
<empty/>
</element>
</optional>
<optional>
<element name="apic">
<ref name="featuretoggle"/>
<empty/>
</element>
</optional>
<optional>
<element name="cpuselection">
<empty/>
</element>
</optional>
<optional>
<element name="deviceboot">
<empty/>
</element>
</optional>
<optional>
<element name="disksnapshot">
<ref name="featuretoggle"/>
<empty/>
</element>
</optional>
<optional>
<element name="hap">
<ref name="featuretoggle"/>
<empty/>
</element>
</optional>
</interleave>
</element>
</define>
<define name="featuretoggle">
<attribute name="toggle">
<ref name="virYesNo"/>
</attribute>
<attribute name="default">
<ref name="virOnOff"/>
</attribute>
</define>
<define name="pagesNuma">
<element name="pages">
<ref name="pagesElem"/>
<ref name="unsignedInt"/>
</element>
</define>
<define name="pagesElem">
<optional>
<attribute name="unit">
<ref name="unit"/>
</attribute>
</optional>
<attribute name="size">
<ref name="unsignedInt"/>
</attribute>
</define>
</grammar>