[libvirt] [PATCH] docs: formatdomain: unify naming for CPUs/vCPUs
Katerina Koukiou
kkoukiou at redhat.com
Wed Jul 18 10:09:12 UTC 2018
CPU is an acronym and should be written in uppercase
when part of plain text and not refering to an element.
Signed-off-by: Katerina Koukiou <kkoukiou at redhat.com>
---
As asked in the review here
https://www.redhat.com/archives/libvir-list/2018-July/msg01093.html
docs/formatdomain.html.in | 84 +++++++++++++++++++--------------------
1 file changed, 42 insertions(+), 42 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index b00971a945..d08ede9ab5 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -631,45 +631,45 @@
</dd>
<dt><code>vcpus</code></dt>
<dd>
- The vcpus element allows to control state of individual vcpus.
+ The vcpus element allows to control state of individual vCPUs.
The <code>id</code> attribute specifies the vCPU id as used by libvirt
- in other places such as vcpu pinning, scheduler information and NUMA
- assignment. Note that the vcpu ID as seen in the guest may differ from
- libvirt ID in certain cases. Valid IDs are from 0 to the maximum vcpu
+ in other places such as vCPU pinning, scheduler information and NUMA
+ assignment. Note that the vCPU ID as seen in the guest may differ from
+ libvirt ID in certain cases. Valid IDs are from 0 to the maximum vCPU
count as set by the <code>vcpu</code> element minus 1.
The <code>enabled</code> attribute allows to control the state of the
- vcpu. Valid values are <code>yes</code> and <code>no</code>.
+ vCPU. Valid values are <code>yes</code> and <code>no</code>.
- <code>hotpluggable</code> controls whether given vcpu can be hotplugged
- and hotunplugged in cases when the cpu is enabled at boot. Note that
- all disabled vcpus must be hotpluggable. Valid values are
+ <code>hotpluggable</code> controls whether given vCPU can be hotplugged
+ and hotunplugged in cases when the CPU is enabled at boot. Note that
+ all disabled vCPUs must be hotpluggable. Valid values are
<code>yes</code> and <code>no</code>.
- <code>order</code> allows to specify the order to add the online vcpus.
- For hypervisors/platforms that require to insert multiple vcpus at once
- the order may be duplicated across all vcpus that need to be
- enabled at once. Specifying order is not necessary, vcpus are then
+ <code>order</code> allows to specify the order to add the online vCPUs.
+ For hypervisors/platforms that require to insert multiple vCPUs at once
+ the order may be duplicated across all vCPUs that need to be
+ enabled at once. Specifying order is not necessary, vCPUs are then
added in an arbitrary order. If order info is used, it must be used for
- all online vcpus. Hypervisors may clear or update ordering information
+ all online vCPUs. Hypervisors may clear or update ordering information
during certain operations to assure valid configuration.
- Note that hypervisors may create hotpluggable vcpus differently from
- boot vcpus thus special initialization may be necessary.
+ Note that hypervisors may create hotpluggable vCPUs differently from
+ boot vCPUs thus special initialization may be necessary.
- Hypervisors may require that vcpus enabled on boot which are not
+ Hypervisors may require that vCPUs enabled on boot which are not
hotpluggable are clustered at the beginning starting with ID 0. It may
- be also required that vcpu 0 is always present and non-hotpluggable.
+ be also required that vCPU 0 is always present and non-hotpluggable.
- Note that providing state for individual cpus may be necessary to enable
+ Note that providing state for individual CPUs may be necessary to enable
support of addressable vCPU hotplug and this feature may not be
supported by all hypervisors.
- For QEMU the following conditions are required. Vcpu 0 needs to be
- enabled and non-hotpluggable. On PPC64 along with it vcpus that are in
- the same core need to be enabled as well. All non-hotpluggable cpus
- present at boot need to be grouped after vcpu 0.
+ For QEMU the following conditions are required. vCPU 0 needs to be
+ enabled and non-hotpluggable. On PPC64 along with it vCPUs that are in
+ the same core need to be enabled as well. All non-hotpluggable CPUs
+ present at boot need to be grouped after vCPU 0.
<span class="since">Since 2.2.0 (QEMU only)</span>
</dd>
</dl>
@@ -774,11 +774,11 @@
<dt><code>vcpupin</code></dt>
<dd>
The optional <code>vcpupin</code> element specifies which of host's
- physical CPUs the domain VCPU will be pinned to. If this is omitted,
+ physical CPUs the domain vCPU will be pinned to. If this is omitted,
and attribute <code>cpuset</code> of element <code>vcpu</code> is
not specified, the vCPU is pinned to all the physical CPUs by default.
It contains two required attributes, the attribute <code>vcpu</code>
- specifies vcpu id, and the attribute <code>cpuset</code> is same as
+ specifies vCPU id, and the attribute <code>cpuset</code> is same as
attribute <code>cpuset</code> of element <code>vcpu</code>.
(NB: Only qemu driver support)
<span class="since">Since 0.9.0</span>
@@ -786,7 +786,7 @@
<dt><code>emulatorpin</code></dt>
<dd>
The optional <code>emulatorpin</code> element specifies which of host
- physical CPUs the "emulator", a subset of a domain not including vcpu
+ physical CPUs the "emulator", a subset of a domain not including vCPU
or iothreads will be pinned to. If this is omitted, and attribute
<code>cpuset</code> of element <code>vcpu</code> is not specified,
"emulator" is pinned to all the physical CPUs by default. It contains
@@ -820,7 +820,7 @@
<dt><code>period</code></dt>
<dd>
The optional <code>period</code> element specifies the enforcement
- interval(unit: microseconds). Within <code>period</code>, each vcpu of
+ interval(unit: microseconds). Within <code>period</code>, each vCPU of
the domain will not be allowed to consume more than <code>quota</code>
worth of runtime. The value should be in range [1000, 1000000]. A period
with value 0 means no value.
@@ -835,7 +835,7 @@
vCPU threads, which means that it is not bandwidth controlled. The value
should be in range [1000, 18446744073709551] or less than 0. A quota
with value 0 means no value. You can use this feature to ensure that all
- vcpus run at the same speed.
+ vCPUs run at the same speed.
<span class="since">Only QEMU driver support since 0.9.4, LXC since
0.9.10</span>
</dd>
@@ -864,7 +864,7 @@
<dd>
The optional <code>emulator_period</code> element specifies the enforcement
interval(unit: microseconds). Within <code>emulator_period</code>, emulator
- threads(those excluding vcpus) of the domain will not be allowed to consume
+ threads(those excluding vCPUs) of the domain will not be allowed to consume
more than <code>emulator_quota</code> worth of runtime. The value should be
in range [1000, 1000000]. A period with value 0 means no value.
<span class="since">Only QEMU driver support since 0.10.0</span>
@@ -873,9 +873,9 @@
<dd>
The optional <code>emulator_quota</code> element specifies the maximum
allowed bandwidth(unit: microseconds) for domain's emulator threads(those
- excluding vcpus). A domain with <code>emulator_quota</code> as any negative
+ excluding vCPUs). A domain with <code>emulator_quota</code> as any negative
value indicates that the domain has infinite bandwidth for emulator threads
- (those excluding vcpus), which means that it is not bandwidth controlled.
+ (those excluding vCPUs), which means that it is not bandwidth controlled.
The value should be in range [1000, 18446744073709551] or less than 0. A
quota with value 0 means no value.
<span class="since">Only QEMU driver support since 0.10.0</span>
@@ -2131,13 +2131,13 @@
QEMU, the user-configurable extended TSEG feature was unavailable up
to and including <code>pc-q35-2.9</code>. Starting with
<code>pc-q35-2.10</code> the feature is available, with default size
- 16 MiB. That should suffice for up to roughly 272 VCPUs, 5 GiB guest
+ 16 MiB. That should suffice for up to roughly 272 vCPUs, 5 GiB guest
RAM in total, no hotplug memory range, and 32 GiB of 64-bit PCI MMIO
- aperture. Or for 48 VCPUs, with 1TB of guest RAM, no hotplug DIMM
+ aperture. Or for 48 vCPUs, with 1TB of guest RAM, no hotplug DIMM
range, and 32GB of 64-bit PCI MMIO aperture. The values may also vary
based on the loader the VM is using.
</p><p>
- Additional size might be needed for significantly higher VCPU counts
+ Additional size might be needed for significantly higher vCPU counts
or increased address space (that can be memory, maxMemory, 64-bit PCI
MMIO aperture size; roughly 8 MiB of TSEG per 1 TiB of address space)
which can also be rounded up.
@@ -2147,7 +2147,7 @@
documentation of the guest OS or loader (if there is any), or test
this by trial-and-error changing the value until the VM boots
successfully. Yet another guiding value for users might be the fact
- that 48 MiB should be enough for pretty large guests (240 VCPUs and
+ that 48 MiB should be enough for pretty large guests (240 vCPUs and
4TB guest RAM), but it is on purpose not set as default as 48 MiB of
unavailable RAM might be too much for small guests (e.g. with 512 MiB
of RAM).
@@ -2425,7 +2425,7 @@
</tr>
<tr>
<td><code>cpu_cycles</code></td>
- <td>the count of cpu cycles (total/elapsed)</td>
+ <td>the count of CPU cycles (total/elapsed)</td>
<td><code>perf.cpu_cycles</code></td>
</tr>
<tr>
@@ -2460,25 +2460,25 @@
</tr>
<tr>
<td><code>stalled_cycles_frontend</code></td>
- <td>the count of stalled cpu cycles in the frontend of the instruction
+ <td>the count of stalled CPU cycles in the frontend of the instruction
processor pipeline by applications running on the platform</td>
<td><code>perf.stalled_cycles_frontend</code></td>
</tr>
<tr>
<td><code>stalled_cycles_backend</code></td>
- <td>the count of stalled cpu cycles in the backend of the instruction
+ <td>the count of stalled CPU cycles in the backend of the instruction
processor pipeline by applications running on the platform</td>
<td><code>perf.stalled_cycles_backend</code></td>
</tr>
<tr>
<td><code>ref_cpu_cycles</code></td>
- <td>the count of total cpu cycles not affected by CPU frequency scaling
+ <td>the count of total CPU cycles not affected by CPU frequency scaling
by applications running on the platform</td>
<td><code>perf.ref_cpu_cycles</code></td>
</tr>
<tr>
<td><code>cpu_clock</code></td>
- <td>the count of cpu clock time, as measured by a monotonic
+ <td>the count of CPU clock time, as measured by a monotonic
high-resolution per-CPU timer, by applications running on
the platform</td>
<td><code>perf.cpu_clock</code></td>
@@ -2505,7 +2505,7 @@
</tr>
<tr>
<td><code>cpu_migrations</code></td>
- <td>the count of cpu migrations, that is, where the process
+ <td>the count of CPU migrations, that is, where the process
moved from one logical processor to another, by
applications running on the platform</td>
<td><code>perf.cpu_migrations</code></td>
@@ -5621,8 +5621,8 @@ qemu-kvm -net nic,model=? /dev/null
The resulting difference, according to the qemu developer who
added the option is: "bh makes tx more asynchronous and reduces
latency, but potentially causes more processor bandwidth
- contention since the cpu doing the tx isn't necessarily the
- cpu where the guest generated the packets."<br/><br/>
+ contention since the CPU doing the tx isn't necessarily the
+ CPU where the guest generated the packets."<br/><br/>
<b>In general you should leave this option alone, unless you
are very certain you know what you are doing.</b>
--
2.17.1
More information about the libvir-list
mailing list