From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48627) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYGsl-0007WM-4u for qemu-devel@nongnu.org; Fri, 03 May 2013 10:22:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UYGsi-0008Ki-GT for qemu-devel@nongnu.org; Fri, 03 May 2013 10:22:43 -0400 Received: from cantor2.suse.de ([195.135.220.15]:36226 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYGsi-0008Jy-6e for qemu-devel@nongnu.org; Fri, 03 May 2013 10:22:40 -0400 Message-ID: <5183C82B.9000306@suse.de> Date: Fri, 03 May 2013 16:22:35 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: 20130419195822.GG2900@otherpad.lan.raisama.net <5183C0BA.9010403@linux.vnet.ibm.com> In-Reply-To: <5183C0BA.9010403@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC/PATCH 0/1] cpu hotplug for s390 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: jjherne@linux.vnet.ibm.com Cc: Eduardo Habkost , Alexander Graf , qemu-devel , Christian Borntraeger , Jens Freimann , Igor Mammedov Hi, Am 03.05.2013 15:50, schrieb Jason J. Herne: > I've done some investigating into using the device_add hmp/qmp command > to support hot-plugging cpus on S390. The alternative suggestion was t= o > simply use a new cpu_add hmp/qmp command. A cpu-add QMP command has been merged by now. Using it with qemu-system-s390x machines will return a QMP error at the moment. > 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"= . In theory we do, ever since making the CPU a device, it just didn't fully work yet. For all QOM'ified CPUs (i.e., not x86) it should work crash-free now, but it's untested whether a particular machine copes with it or not. > 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 ar= e > created in this case: > qemu -smp 2 -device cpu,id=3Dcpu0 -device cpu,id=3Dcpu1, -device > cpu,id=3Dcpu2 Four, if the correct driver is supplied (error for the above). The -smp option indicates how many CPUs the *machine* instantiates. In addition you are trying to create two further devices, just like other machines create a PCI host bridge and a user might try to add another one. > Is -smp invalid when cpu devices are specified? We would have to fill > the smp_cpus variable after all (cpu) devices have been parsed. Would we? If so, doing some check of -smp maxcpus and/or updating whatever variable in CPU's realizefn feels more natural to me than some post-whatever hook. > 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 t= o > 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? You are saying that based on the current s390 code. Actually it was discussed that s390-cpu should be abstract as well and the type should indicate the actual model - host-s390-cpu, z9-s390-cpu, etc. There were two KVM calls that covered future structure of CPU modelling (socket -> core -> thread) and roadmap towards vCPU hotplug - see the minutes on the list. The current approach of cpu-add for 1.5 was chosen because the refactoring of CPUArchState is rather cumbersome and taking too long. > Another issue is that the s390-cpu QOM object class is a child of > "main-system-bus". [...] That's not true, it is not on any bus at all - I have attempted to fix device_add for this use case and Igor has just sent a patch for unplug. For x86 we have chosen to introduce the ICC bus to handle hot-adding APIC devices (which were on SysBus before) alongside the CPU. With proper CPU modelling that would not be necessary, but for now it has the advantage of giving us a canonical QOM path to the CPUs for free. Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg