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, remove any reference to any
specific value for the attributes having any special meaning
attached to it.

In fact, since there are plans to make it possible to create
guests with multiple CPU clusters on x86_64, rework the note
into a more generic warning cautioning users that an attribute
showing up here does not imply that the same attribute can be
used when defining a guest CPU topology.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
---
 docs/formatcaps.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/formatcaps.rst b/docs/formatcaps.rst
index f37532296f..68477e639f 100644
--- a/docs/formatcaps.rst
+++ b/docs/formatcaps.rst
@@ -74,14 +74,14 @@ 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, even if this attribute is present, you might not be able to
+     define guests with multiple CPU dies.
 
    ``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, even if this attribute is present, you might not be able to
+     define guests with multiple CPU clusters.
 
    ``core_id``
      Identifier for the core the CPU is in.
-- 
2.43.0
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org

On Thu, Feb 08, 2024 at 06:34:37PM +0100, Andrea Bolognani wrote:
> 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, remove any reference to any
> specific value for the attributes having any special meaning
> attached to it.
> 
> In fact, since there are plans to make it possible to create
> guests with multiple CPU clusters on x86_64, rework the note
> into a more generic warning cautioning users that an attribute
> showing up here does not imply that the same attribute can be
> used when defining a guest CPU topology.
> 
> Signed-off-by: Andrea Bolognani <abologna@redhat.com>
> ---
>  docs/formatcaps.rst | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)

Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
_______________________________________________
Devel mailing list -- devel@lists.libvirt.org
To unsubscribe send an email to devel-leave@lists.libvirt.org