From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfSrH-0002qv-34 for qemu-devel@nongnu.org; Tue, 07 Apr 2015 08:44:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YfSrA-0003xD-3J for qemu-devel@nongnu.org; Tue, 07 Apr 2015 08:43:59 -0400 Received: from e06smtp16.uk.ibm.com ([195.75.94.112]:53112) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YfSr9-0003wb-Om for qemu-devel@nongnu.org; Tue, 07 Apr 2015 08:43:52 -0400 Received: from /spool/local by e06smtp16.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 7 Apr 2015 13:43:48 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 050A1219005C for ; Tue, 7 Apr 2015 13:43:33 +0100 (BST) Received: from d06av12.portsmouth.uk.ibm.com (d06av12.portsmouth.uk.ibm.com [9.149.37.247]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t37ChkLX54526176 for ; Tue, 7 Apr 2015 12:43:46 GMT Received: from d06av12.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av12.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t37ChiLF000473 for ; Tue, 7 Apr 2015 06:43:45 -0600 Message-ID: <5523D0FF.7090609@de.ibm.com> Date: Tue, 07 Apr 2015 14:43:43 +0200 From: Christian Borntraeger MIME-Version: 1.0 References: <1427131923-4670-1-git-send-email-afaerber@suse.de> In-Reply-To: <1427131923-4670-1-git-send-email-afaerber@suse.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] cpu modelling and hotplug (was: [PATCH RFC 0/4] target-i386: PC socket/core/thread modeling, part 1) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Peter Maydell , Eduardo Habkost , Alexander Graf , Paolo Bonzini , "Jason J. Herne" , Bharata B Rao , Cornelia Huck , Igor Mammedov , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , david@gibson.dropbear.id.au We had a call and I was asked to write a summary about our conclusion. The more I wrote, there more I became uncertain if we really came to a conclusion and became more certain that we want to define the QMP/HMP/CLI interfaces first (or quite early in the process) As discussed I will provide an initial document as a discussion starter So here is my current understanding with each piece of information on one line, so that everybody can correct me or make additions: current wrap-up of architecture support ------------------- x86 - Topology possible - can be hierarchical - interfaces to query topology - SMT: fanout in host, guest uses host threads to back guest vCPUS - supports cpu hotplug via cpu_add power - Topology possible - interfaces to query topology? - SMT: Power8: no threads in host and full core passed in due to HW design may change in the future s/390 - Topology possible - can be hierarchical - interfaces to query topology - always virtualized via PR/SM LPAR - host topology from LPAR can be heterogenous (e.g. 3 cpus in 1st socket, 4 in 2nd) - SMT: fanout in host, guest uses host threads to back guest vCPUS Current downsides of CPU definitions/hotplug ----------------------------------------------- - smp, sockets=,cores=,threads= builds only homogeneous topology - cpu_add does not tell were to add - artificial icc bus construct on x86 for several reasons (link, sysbus not hotpluggable..) discussions ------------------- - we want to be able to (most important question, IHMO) - hotplug CPUs on power/x86/s390 and maybe others - define topology information - bind the guest topology to the host topology in some way - to host nodes - maybe also for gang scheduling of threads (might face reluctance from the linux scheduler folks) - not really deeply outlined in this call - QOM links must be allocated at boot time, but can be set later on - nothing that we want to expose to users - Machine provides QOM links that the device_add hotplug mechanism can use to add new CPUs into preallocated slots. "CPUs" can be groups of cores and/or threads. - hotplug and initial config should use same semantics - cpu and memory topology might be somewhat independent --> - define nodes - map CPUs to nodes - map memory to nodes - hotplug per - socket - core - thread ? Now comes the part where I am not sure if we came to a conclusion or not: - hotplug/definition per core (but not per thread) seems to handle all cases - core might have multiple threads ( and thus multiple cpustates) - as device statement (or object?) - mapping of cpus to nodes or defining the topology not really outlined in this call To be defined: - QEMU command line for initial setup - QEMU hmp/qmp interfaces for dynamic setup Christian