On Tue, Feb 06, 2024 at 06:42:22PM +0000, Daniel P. Berrangé wrote:
On Tue, Feb 06, 2024 at 07:04:30PM +0100, Andrea Bolognani wrote:
> ``die_id``
> Identifier for the die the CPU is in.
>
> + 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.
I would remove the caveat about "not all architectures support CPU dies"
entirely, and about special die id values. I tend to say that every CPU
every manufactured supports "dies", but that most CPUs dont support more
than 1 die :-)
The purpose of exposing this info is primarily to help apps / admins
in placing guests, and matching host / guest topology where applicable.
To do that they don't need to care if a CPU supports more than 1 die
or not, they just need to see the topology reported.
If they do want to detect >1 die for some reason though, they should
not try to look for special 'die_id' values, instead look to see if
there are more than 1 *distinct* die_id within a single socket_id.
That's fair, but I think it could still be useful to highlight that
the presence of the attribute in the *host* topology doesn't indicate
that attempting to use it in the *guest* topology will work, just to
avoid confusion.
How about
Note that this attribute is always present, even when the
architecture doesn't support guests with multiple CPU dies.
(and the same for clusters, of course)?
--
Andrea Bolognani / Red Hat / Virtualization