On Thu, Feb 08, 2024 at 03:54:20PM +0000, Daniel P. Berrangé wrote: > On Thu, Feb 08, 2024 at 07:52:00AM -0800, Andrea Bolognani wrote: > > > > 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. AFAICT there's no x86_64 (or ppc64, or s390x, or ...) machine type that can use CPU clusters. So if you're planning to run a same-architecture VM (most common use case) you are not going to be able to use CPU clusters, which might be confusing considering that CPU clusters appear to be supported by your host CPU according to the capabilities XML. This is the potential source of confusion that I'm trying to address with the patch. I don't see how *not* mentioning this is going to be more helpful to users. -- Andrea Bolognani / Red Hat / Virtualization _______________________________________________ Devel mailing list -- devel@xxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxx
