We're not mentioning that we're replicating QEMU behavior on purpose.
First because QEMU will one day, maybe, change the behavior and
start to refuse incomplete NUMA setups, and then our documentation
is now deprecated. Second, auto filling the CPUs in the first
cell will work regardless of QEMU changes in the future.
The idea is to encourage the user to provide a complete NUMA CPU topology,
not relying on the CPU auto fill mechanic.
Signed-off-by: Daniel Henrique Barboza <danielhb413@xxxxxxxxx>
---
docs/formatdomain.html.in | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 20c28a47e3..07d0fa5c70 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -1829,7 +1829,16 @@
<p>
Each <code>cell</code> element specifies a NUMA cell or a NUMA node.
<code>cpus</code> specifies the CPU or range of CPUs that are
- part of the node. <code>memory</code> specifies the node memory
+ part of the node. <span class="since">Since 6.5.0</span> For the qemu
+ driver, if the emulator binary supports disjointed <code>cpus</code> ranges
+ in each <code>cell</code>, the sum of all CPUs declared in each <code>cell</code>
+ will be matched with the maximum number of virtual CPUs declared in the
+ <code>vcpu</code> element. This is done by filling any remaining CPUs
+ into the first NUMA <code>cell</code>. Users are encouraged to supply a
+ complete NUMA topology, where the sum of the NUMA CPUs matches the maximum
+ virtual CPUs number declared in <code>vcpus</code>, to make the domain
+ consistent across qemu and libvirt versions.
+ <code>memory</code> specifies the node memory
in kibibytes (i.e. blocks of 1024 bytes).
<span class="since">Since 1.2.11</span> one can use an additional <a
href="#elementsMemoryAllocation"><code>unit</code></a> attribute to
--
2.26.2
