I've seen examples in the wild of the cluster attribute having
non-zero value on x86_64.
This is obviously quite confusing, but it's the information that
Linux exposes to userspace and we don't really have a way to tell
apart a valid die/cluster ID from a dummy one.
What ultimately matters is that the underlying assumptions about
topology are respected, which they are: in the x86_64 cases that
I have analyzed, for example, each "cluster" contained exactly
one core, so any program that would use this information to
influence guest topology decisions would be unaffected by the
additional level showing up in the hierarchy.
In an attempt to reduce confusion, document that the value for
these attributes is not necessarily going to be zero.
Signed-off-by: Andrea Bolognani <abologna@xxxxxxxxxx>
---
docs/formatcaps.rst | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/docs/formatcaps.rst b/docs/formatcaps.rst
index f37532296f..c15d391b63 100644
--- a/docs/formatcaps.rst
+++ b/docs/formatcaps.rst
@@ -74,14 +74,18 @@ The ``<host/>`` element consists of the following child elements:
``die_id``
Identifier for the die the CPU is in.
- Note that not all architectures support CPU dies: if the current
- architecture doesn't, the value will be 0 for all CPUs.
+ Note that, while not all architectures support CPU dies, this attribute
+ will always be present in the capabilities XML. If the architecture
+ doesn't support them, the value will likely be 0 for all CPUs, but it
+ could also be some other arbitrary value.
``cluster_id``
Identifier for the cluster the CPU is in.
- Note that not all architectures support CPU clusters: if the current
- architecture doesn't, the value will be 0 for all CPUs.
+ Note that, while not all architectures support CPU clusters, this
+ attribute will always be present in the capabilities XML. If the
+ architecture doesn't support them, the value will likely be 0 for all
+ CPUs, but it could also be some other arbitrary value.
``core_id``
Identifier for the core the CPU is in.
--
2.43.0
_______________________________________________
Devel mailing list -- devel@xxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
