From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54965) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8MaI-0000vh-2W for qemu-devel@nongnu.org; Mon, 14 Dec 2015 01:26:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a8MaE-0007Ic-RD for qemu-devel@nongnu.org; Mon, 14 Dec 2015 01:26:10 -0500 Received: from e28smtp08.in.ibm.com ([125.16.236.8]:59899) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a8MaE-0007IM-5m for qemu-devel@nongnu.org; Mon, 14 Dec 2015 01:26:06 -0500 Received: from localhost by e28smtp08.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 14 Dec 2015 11:56:02 +0530 Received: from d28relay05.in.ibm.com (d28relay05.in.ibm.com [9.184.220.62]) by d28dlp03.in.ibm.com (Postfix) with ESMTP id BE19D1258065 for ; Mon, 14 Dec 2015 11:56:25 +0530 (IST) Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay05.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id tBE6PwXQ7012840 for ; Mon, 14 Dec 2015 11:55:58 +0530 Received: from d28av03.in.ibm.com (localhost [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id tBE6Pvcx002320 for ; Mon, 14 Dec 2015 11:55:58 +0530 Date: Mon, 14 Dec 2015 11:55:56 +0530 From: Bharata B Rao Message-ID: <20151214062556.GE18759@in.ibm.com> References: <1449728144-6223-1-git-send-email-bharata@linux.vnet.ibm.com> <5669DFD1.5070607@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5669DFD1.5070607@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [RFC PATCH v0 0/9] Generic cpu-core device Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Matthew Rosato Cc: peter.maydell@linaro.org, ehabkost@redhat.com, agraf@suse.de, qemu-devel@nongnu.org, borntraeger@de.ibm.com, pbonzini@redhat.com, imammedo@redhat.com, afaerber@suse.de, david@gibson.dropbear.id.au On Thu, Dec 10, 2015 at 03:25:53PM -0500, Matthew Rosato wrote: > On 12/10/2015 01:15 AM, Bharata B Rao wrote: > > Hi, > > > > This is an attempt to define a generic CPU device that serves as a > > containing device to underlying arch-specific CPU devices. The motivation > > for this is to have an arch-neutral way to specify CPUs mainly during > > hotplug. > > > > Instead of individual archs having their own semantics to specify the > > CPU like > > > > -device POWER8-powerpc64-cpu (pseries) > > -device qemu64-x86_64-cpu (pc) > > -device s390-cpu (s390) > > > > this patch introduces a new device named cpu-core that could be > > used for all target archs as > > > > -device cpu-core,socket="sid" > > > > This adds a CPU core with all its associated threads into the specified > > socket with id "sid". The number of target architecture specific CPU threads > > that get created during this operation is based on the CPU topology specified > > using -smp sockets=S,cores=C,threads=T option. Also the number of cores that > > can be accommodated in the same socket is dictated by the cores= parameter > > in the same -smp option. > > > > CPU sockets are represented by QOM objects and the number of sockets required > > to fit in max_cpus are created at boottime. As cpu-core devices are > > created, they are linked to socket object specified by socket="sid" device > > property. > > > > Thus the model consists of backend socket objects which can be considered > > as container of one or more cpu-core devices. Each cpu-core object is > > linked to the appropriate backend socket object. Each CPU thread device > > appears as child object of cpu-core device. > > > > All the required socket objects are created upfront and they can't be deleted. > > Though currently socket objects can be created using object_add monitor > > command, I am planning to prevent that so that a guest boots with the > > required number of sockets and only CPU cores can be hotplugged into > > them. > > > > CPU hotplug granularity > > ----------------------- > > CPU hotplug will now be done in cpu-core device granularity. > > > > This patchset includes a patch to prevent topologies that result in > > partially filled cores. Hence with this patchset, we will always > > have fully filled cpu-core devices both for boot time and during hotplug. > > > > For archs like PowerPC, where there is no requirement to be fully > > similar to the physical system, hotplugging CPU at core granularity > > is common. While core level hotplug will fit in naturally for such > > archs, for others which want socket level hotplug, could higher level > > tools like libvirt perform multiple core hotplugs in response to one > > socket hotplug request ? > > > > Are there archs that would need thread level CPU addition ? > > > > Boot time CPUs as cpu-core devices > > ---------------------------------- > > In this patchset, I am coverting the boot time CPU initialization > > (from -smp option) to initialize the required number of cpu-core > > devices and linking them with the appropriate socket objects. > > > > Initially I thought we should be able to completely replace -smp with > > -device cpu-core, but then I realized that at least both x86 and pseries > > guests' machine init code has dependencies on first CPU being available > > for the machine init code to work correctly. > > > > Currently I have converted boot CPUs to cpu-core devices only PowerPC sPAPR > > and i386 PC targets. I am not really sure about the i386 changes and the > > intention in this iteration was to check if it is indeed possible to > > fit i386 into cpu-core model. Having said that I am able to boot an x86 > > guest with this patchset. > > I attempted a quick conversion for s390 to using cpu-core, but looks > like we'd have an issue preventing s390 from using cpu-core immediately > -- it relies on cpu_generic_init, which s390 specifically avoids today > because we don't have support for cpu_models. Not sure if other > architectures will have the same issue. I see that there are a few archs that don't have cpu_model, I guess we can teach cpu_generic_init() to handle that. I will attempt that in the next version if needed. Regards, Bharata.