From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35904) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zp4ha-000315-Lr for qemu-devel@nongnu.org; Wed, 21 Oct 2015 21:30:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zp4hM-0007HC-D8 for qemu-devel@nongnu.org; Wed, 21 Oct 2015 21:29:49 -0400 Received: from [59.151.112.132] (port=62106 helo=heian.cn.fujitsu.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zp4hL-0007Gg-MA for qemu-devel@nongnu.org; Wed, 21 Oct 2015 21:29:44 -0400 Message-ID: <56283B9C.8040808@cn.fujitsu.com> Date: Thu, 22 Oct 2015 09:27:56 +0800 From: Zhu Guihua MIME-Version: 1.0 References: <1427131923-4670-1-git-send-email-afaerber@suse.de> <5523D0FF.7090609@de.ibm.com> In-Reply-To: <5523D0FF.7090609@de.ibm.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] cpu modelling and hotplug List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Christian Borntraeger , qemu-devel@nongnu.org Cc: Peter Maydell , Eduardo Habkost , Igor Mammedov , Alexander Graf , "Jason J. Herne" , Bharata B Rao , Cornelia Huck , Paolo Bonzini , =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= , david@gibson.dropbear.id.au Hi all, May I know whether the discussion is still ongoing? I checked Andreas's git tree, there was no changes about the topology. Plz let me know the schedule about this. Thanks, Zhu On 04/07/2015 08:43 PM, Christian Borntraeger wrote: > 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 > > > . >