On Thu, Jan 17, 2019 at 09:18:29AM +0800, Like Xu wrote: > On 2019/1/17 2:26, Daniel P. Berrangé wrote: > > On Mon, Jan 14, 2019 at 06:51:34PM -0200, Eduardo Habkost wrote: > > > On Mon, Jan 14, 2019 at 08:24:56PM +0800, Like Xu wrote: > > > > This patch updates the check rules on legeacy -smp parse from user > > > > command > > > > and it's designed to obey the same restrictions as socket/core/thread > > > > model. > > > > > > > > Signed-off-by: Like Xu <[email protected]> > > > > > > This would require the documentation for -smp to be updated. > > > qemu-options.hx still says that "cores=" is the number of cores > > > per socket. > > > > > > Also, I'm not completely sure we should change the meaning of > > > "cores=" and smp_cores to be per-die instead of per-socket. Most > > > machines won't have any code for tracking dies, so we probably > > > shouldn't make the extra complexity affect all machines.[1] > > > > Could we not simply have a 'max-dies' property against the machine > > base class which defaults to 1. Then no existing machine types > > need any changes unless they want to opt-in to supporting > > "dies > 1". > It's nice to have max-dies for machine base class. > > > > > What would be the disadvantages of a simple -machine > > > "dies-per-socket" option, specific for PC? > > > > Libvirt currently has > > > > <cpu> > > <topology sockets='1' cores='2' threads='1'/> > > </cpu> > > > > To me the natural way to expand that is to use > > > > <cpu> > > <topology sockets='1' dies='2' cores='2' threads='1'/> > > </cpu> > > > > but this rather implies dies-per-socket + cores-per-die > > not cores-per-socket. Libvirt could of course convert > > its value from cores-per-die into cores-per-socket > > before giving it to QEMU, albeit with the potential > > for confusion from people comparing the libvirt and QEMU > > level configs > It is a recommended update on cpu topo configuration of libvirt > as well as other upper layer apps. > > > > > Keeping core-id and smp_cores per-socket instead of per-die also > > > seems necessary to keep backwards compatibility on the interface > > > for identifying CPU hotplug slots. Igor, what do you think? > > > > Is there really a backwards compatibility problem, given that > > no existing mgmt app will have created a VM with "dies != 1". > > IOW, if an application adds logic to support configuring a > > VM with "dies > 1" it seems fine that they should need to > > understand how this impacts the way you identify CPUs for > > hotplug. > The impacts from MCP model will be documented continuously. > Any concerns for hot-plugging CPUs in MCP socket is welcomed. > > > > > [1] I would even argue that the rest of the -smp options belong > > > to the machine object, and topology rules should be > > > machine-specific, but cleaning this up will require > > > additional work. > > > > If we ever expect to support non-homogenous CPUs then our > > modelling of topology is fatally flawed, as it doesm't allow > > us to specify creating a VM with 1 socket containing 2 > > cores and a second socket containing 4 cores. Fixing that > > might require modelling each socket, die, and core as a > > distinct set of nested QOM objects which gets real fun. > Do we really need to go out of this non-homogeneous step？ > Currently there is no support on physical host AFAIK. > Is there enough benefit?
I'm not suggesting we need to solve this now - I just meant to indicate that we shouldn't over-think representing of the 'dies' parameter today, because any problems with the simple solution you proposed are negligible compared to the problem of non-homogeneous CPUs. IOW, I think it is fine to keep your simple proposal now. Worry about the hard problems later when we'll need better modelling of everything. 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 :|
