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

[Igor Mammedov]

On Tue, 10 May 2016 17:24:14 -0300
Eduardo Habkost <address@hidden> 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 <address@hidden>  
> 
> 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.