From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYGOM-0002Jq-D9 for qemu-devel@nongnu.org; Fri, 03 May 2013 09:51:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UYGOJ-0006R9-9w for qemu-devel@nongnu.org; Fri, 03 May 2013 09:51:18 -0400 Received: from e9.ny.us.ibm.com ([32.97.182.139]:40339) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYGOJ-0006O9-69 for qemu-devel@nongnu.org; Fri, 03 May 2013 09:51:15 -0400 Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 3 May 2013 09:50:55 -0400 Received: from d01relay07.pok.ibm.com (d01relay07.pok.ibm.com [9.56.227.147]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 69ACD38C8047 for ; Fri, 3 May 2013 09:50:52 -0400 (EDT) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay07.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r43Doqdn58065078 for ; Fri, 3 May 2013 09:50:52 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r43Dop68015264 for ; Fri, 3 May 2013 09:50:51 -0400 Message-ID: <5183C0BA.9010403@linux.vnet.ibm.com> Date: Fri, 03 May 2013 09:50:50 -0400 From: "Jason J. Herne" MIME-Version: 1.0 References: 20130419195822.GG2900@otherpad.lan.raisama.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC/PATCH 0/1] cpu hotplug for s390 Reply-To: jjherne@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: ehabkost@redhat.com, "qemu-devel@nongnu.org qemu-devel" , Christian Borntraeger , Jens Freimann , imammedo@redhat.com, afaerber@suse.de, Alexander Graf I've done some investigating into using the device_add hmp/qmp command to support hot-plugging cpus on S390. The alternative suggestion was to simply use a new cpu_add hmp/qmp command. device_add accepts all of the same options as the -device command line parameter takes. This would imply that to hot-plug cpu's using device add we would need to allow command line arguments of type "-device cpu". All of the implications of this are not currently clear to me. How would this interact with the -smp option, for example, how many cpus are created in this case: qemu -smp 2 -device cpu,id=cpu0 -device cpu,id=cpu1, -device cpu,id=cpu2 Is -smp invalid when cpu devices are specified? We would have to fill the smp_cpus variable after all (cpu) devices have been parsed. Since device_add requires a QOM object name (driver parameter) we seem to have two choices. 1. device_add cpu 2. device_add s390-cpu But "cpu" is actually an abstract QOM class and cannot be instantiated by object_new("cpu") as is done in device_add processing. So we need to use "s390-cpu". This adds an architecture specific flavor to cpu hotplug. I would think we'd want to avoid that somehow. perhaps we simply "translate" that parameter during early device_add processing? Another issue is that the s390-cpu QOM object class is a child of "main-system-bus". This bus does not support hotplug: sysbus->allow_hotplug=0. In order to implement cpu hotplug we would need to either switch sysbus->allow_hotplug to 1, or the s390-cpu QOM object class would need to move to a bus that supports hotplug. I'm not sure what the implications of either choice would be. I'm interested in thoughts and comments. Thanks! -- -- Jason J. Herne (jjherne@linux.vnet.ibm.com)