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 _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
