From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juan Quintela Subject: KVM call minutes for 2016-02-16 Date: Tue, 16 Feb 2016 18:28:06 +0100 Message-ID: <8737ss7eft.fsf@emacs.mitica> Reply-To: quintela@redhat.com Mime-Version: 1.0 Content-Type: text/plain To: KVM devel mailing list , qemu-devel Return-path: Received: from mx1.redhat.com ([209.132.183.28]:57545 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753227AbcBPR2K (ORCPT ); Tue, 16 Feb 2016 12:28:10 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 6849D7AE8A for ; Tue, 16 Feb 2016 17:28:10 +0000 (UTC) Sender: kvm-owner@vger.kernel.org List-ID: Hi Ramdom ideas that I took for the talk, I hope that some of the active participants can reply with a more coherent viewe. State of the art (Andreas) - Having very specific socket objects - Dynamic allocation using new parameters - Which level should we be doing the hotplug (granularuty) x86-> socket level powerpc -> core z390 -> thread level Christin - Low level device adding - Initialize from the beggining all cpu objects Hot-plugging would be to put them on-line - how cpu came into being - how are we going to add in x86 with device add * x86 and sparc -cpu handling is special case * not copy that on s390, better example in ARM? - Way to handle this? * save the feature string internally, for reusing with new cpu * how best handle, it can depend of cpu model and board * how to make libvirt level not crazy? * should we hide the cpu add inside the machine implementation * having an array of empty sockets where to plug new cpus * only compatible types can be set on link property (not sure how well are enforced) * set the link property of the machine to the core object just created * powerpc cpu object is realized hook should check that it is done is a hot plug operation to automate this * powerpc only has cores and threads * we can have a property in the core object to know where it goes * if each core has two threads, when we add a new core, we always add 2 threads * cpu_add have a type={core,thread,whatever} what is the problem with it? * pre-created id's for cpu_add? * do different implementations and then try to find commonalities. * ARM can need to be able to add different cpu models * how to specify the topology * cpu_add has always thought to be an interim solution until we get the real one * problems with migration, spcially with cpu_del * get cpu_add on x86 * they don't support unplug * they don't support topology * realization matters about where we put the things, in child or parent object Later, JUan.