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@xxxxxxxxxx> 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@xxxxxxxxxx> > > > > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list