Re: [libvirt] [RFC 12/42] pc: initialize legacy hotplug only for 2.6 and older machine types

On Tue, 10 May 2016 17:24:14 -0300 Eduardo Habkost <ehabkost(a)redhat.com&gt; wrote: > On Mon, May 02, 2016 at 02:33:21PM +0200, Igor Mammedov wrote: > > on old machine types CPU hotplug was uncondtionally > > enabled since it was introduced, consuming IO ports > > and providing AML regardles of whether it was actually > > in use or not. Keep it so for 2.6 and older machines. > > > > New machine types will have an option to turn CPU > > hotplug on if it's needed while by default it stays > > disabled not consuming extra RAM/IO resources. > > > > Signed-off-by: Igor Mammedov <imammedo(a)redhat.com&gt; > > What if people are using "-machine pc -smp N,max_cpus=M"? > Shouldn't we at least warning about missing CPU hotplug support > when using just "max_cpus" with no "cpu-hotplug=on" with pc-2.7 > and newer? Yep, I'll add it on next respin. Would hard error better than warning?

> Should max_cpus > smp_cpus automatically set > cpu-hotplug=on? I'd prefer dumb explicit feature enablement, as it doesn't put any assumptions on other options and QEMU + mgmt don't have to maintain logic for implicit rules that might enable it. and if I didn't manage to push 'device_add x86cpu' in 2.7 time frame, guess work gets a bit confusing with current cpu-add semantic, consider current: SRC-QEMU -smp 1,maxcpus=2 cpu-add 1 DST-QEMU -smp 2,maxcpus=2 vs would be device_add: SRC-QEMU -smp 1,maxcpus=2 device_add cpu DST-QEMU -smp 1,maxcpus=2 -device cpu so instead of qemu/users guessing, I suggest to make it explictly enabled to get feature (which is mostly optional) or cleanly fail qemu start if confusing options are specified with a clear error message.