On Thu, Feb 08, 2024 at 07:52:00AM -0800, Andrea Bolognani wrote: > On Thu, Feb 08, 2024 at 03:47:06PM +0000, Daniel P. Berrangé wrote: > > On Thu, Feb 08, 2024 at 07:37:00AM -0800, Andrea Bolognani wrote: > > > 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. > > > > The host topology info says nothing about what's possible in the > > guest. The only requirement for the guest is that QEMU is new > > enough to configure this. Aside from that any combo of sockets/ > > clusters/dies/cores/threads can be configured for the guest, > > regardless of what host topology reports. > > That's not correct. Even the latest version of QEMU only allows > configuring multiple dies and clusters for certain architectures. Yes but that's a constraint of the guest machine type choice, related to the host capabilities info. 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@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
