From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44061) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0c33-0004jJ-H5 for qemu-devel@nongnu.org; Wed, 11 May 2016 17:52:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b0c2x-0005WS-EQ for qemu-devel@nongnu.org; Wed, 11 May 2016 17:52:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45283) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0c2x-0005WM-8D for qemu-devel@nongnu.org; Wed, 11 May 2016 17:51:59 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 97890C04B305 for ; Wed, 11 May 2016 21:51:58 +0000 (UTC) Date: Thu, 12 May 2016 00:51:55 +0300 From: "Michael S. Tsirkin" Message-ID: <20160512005017-mutt-send-email-mst@redhat.com> References: <1462192431-146342-1-git-send-email-imammedo@redhat.com> <1462192431-146342-13-git-send-email-imammedo@redhat.com> <20160510202414.GD4457@thinpad.lan.raisama.net> <20160511155039.320c3de6@nial.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160511155039.320c3de6@nial.brq.redhat.com> Subject: Re: [Qemu-devel] [RFC 12/42] pc: initialize legacy hotplug only for 2.6 and older machine types List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: Eduardo Habkost , qemu-devel@nongnu.org, marcel@redhat.com, eblake@redhat.com, armbru@redhat.com, drjones@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 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 > > > > 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? Most people don't need cpu hotplug, attempts to hotplug fail, should be enough. > > 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.