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

[Eduardo Habkost <ehabkost redhat com>]

On Wed, May 11, 2016 at 03:50:39PM +0200, Igor Mammedov wrote:
> On Tue, 10 May 2016 17:24:14 -0300
> Eduardo Habkost <ehabkost redhat com> 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 redhat com>  
> > 
> > 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?

Not sure. It would break older libvirt versions, wouldn't it?

But: isn't the new legacy-cpu-hotplug=false default going to
break old libvirt versions anyway? Should we?

(CCing libvirt list)

> 
> > 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.

Agreed we shouldn't encourage people to use the old option to get
the new behavior.

But I am worried about breaking existing configurations on a
machine-type change. Is it possible to avoid that?

-- 
Eduardo