From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQuQU-0005Sj-4u for qemu-devel@nongnu.org; Thu, 26 Feb 2015 04:08:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YQuQQ-0000KQ-Ht for qemu-devel@nongnu.org; Thu, 26 Feb 2015 04:08:10 -0500 Received: from cantor2.suse.de ([195.135.220.15]:42478 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YQuQQ-0000KM-Bh for qemu-devel@nongnu.org; Thu, 26 Feb 2015 04:08:06 -0500 Message-ID: <54EEE274.5080008@suse.de> Date: Thu, 26 Feb 2015 10:08:04 +0100 From: =?windows-1252?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <54EBD30C.1040902@cn.fujitsu.com> <54ECAD4D.9030506@suse.de> <20150226044255.GA14967@in.ibm.com> In-Reply-To: <20150226044255.GA14967@in.ibm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH v4 00/10] cpu: add device_add foo-x86_64-cpu support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: bharata@linux.vnet.ibm.com Cc: Zhu Guihua , Eduardo Habkost , qemu-devel@nongnu.org, tangchen@cn.fujitsu.com, chen.fan.fnst@cn.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com, anshul.makkar@profitbricks.com, Gu Zheng , imammedo@redhat.com Am 26.02.2015 um 05:42 schrieb Bharata B Rao: > On Tue, Feb 24, 2015 at 05:56:45PM +0100, Andreas F=E4rber wrote: >> Am 24.02.2015 um 02:25 schrieb Gu Zheng: >>> The issues you commented in the previous version have been fixed in t= his one. >> >> What I have repeatedly rejected is "device_add foo-x86_64-cpu". This i= s >> still in 00/10 and 09/10. Most of the actual changes however do look t= o >> be going in the right direction of making 'realize' work as expected f= or >> foo-x86_64-cpu. >> >> As for the socket-based device_add I mentioned, I had pushed a work >> branch qom-cpu-x86 and had some off-list discussions for some of the >> other architectures but did not submit it as an RFC yet. What I am sti= ll >> working on is dynamic properties to allocate cores (threads TBD) for >> "device_add x86_64-cpu-socket,cores=3Dn". >=20 > If you have started a VM with -smp sockets=3D1,cores=3D4,threads=3D2, w= ill you > allow addition of a socket with just 2 cores like >=20 > device_add x86_64-cpu-socket,cores=3D2,id=3Dsock2 ? In my implementation it is not yet working; with your patch it might, from a QEMU perspective. Whether that is sensible to do on x86 ACPI-/guest-wise is a different question. I didn't want to rule it out, as it seems possible in hardware when Intel/AMD socket types are compatible, and today cpu-add adds them one by one so it's possible. On PowerPC the modeling could be done slightly differently, but as for x86 we'll have to keep in mind that there's not just sPAPR but also baremetal. > If so, will there be semantics to populate the remaining cores of that > socket ? If so, would that look like below ? >=20 > device-add x86_64-cpu-core,sock=3Dsock2 No, that is not possible with my modeling. Hotplug possibilities correspond to link<> properties, whereas my socket proposal uses child<> properties. This in turn has implications on CPU initialization functions, needing to not set realized=3Dtrue. For non-x86 that will involve taking realized=3Dtrue out of cpu_init() and moving it into call sites. Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Felix Imend=F6rffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG N=FCrnberg)