From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:45042) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTBBA-0006QX-GP for qemu-devel@nongnu.org; Fri, 19 Apr 2013 09:16:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UTBB8-0004ZL-If for qemu-devel@nongnu.org; Fri, 19 Apr 2013 09:16:40 -0400 Received: from cantor2.suse.de ([195.135.220.15]:39670 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UTBB8-0004Z7-Ci for qemu-devel@nongnu.org; Fri, 19 Apr 2013 09:16:38 -0400 Message-ID: <517143B4.2060109@suse.de> Date: Fri, 19 Apr 2013 15:16:36 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1364971345-3110-1-git-send-email-jfrei@linux.vnet.ibm.com> <516EE4AD.3090508@suse.de> <20130419075158.GC14662@linux.vnet.ibm.com> In-Reply-To: <20130419075158.GC14662@linux.vnet.ibm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC/PATCH 0/1] cpu hotplug for s390 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jens Freimann Cc: Eduardo Habkost , qemu-devel , Alexander Graf , Christian Borntraeger , Cornelia Huck , Igor Mammedov Am 19.04.2013 09:51, schrieb Jens Freimann: > On Wed, Apr 17, 2013 at 08:06:37PM +0200, Andreas F=E4rber wrote: >> Hi Jens, >> >> Am 03.04.2013 08:42, schrieb Jens Freimann: >>> this is what our approach to CPU hotplug looks like. >>> With respect to Igor's CPU hotplug series, how should we proceed?=20 >>> Should we change the interface to=20 >>> qemu_system_cpu_add_notifier/qemu_system_cpu_hotplug_request/cpu-add = etc? >> >> I am wondering if my recent qdev/device_add fixes would allow to >> implement CPU hot-add via device_add for s390x? >=20 > From what I've seen so far it could be possible, but... Hm, so probably not a good idea? Just looking for a guinea pig for infrastructure testing... >> Background is that for x86 we currently have a flat CPU core/thread >> namespace but would need to deal with sockets, cores and threads to ge= t >> topologies right. I assume there are no such issues on s390x, so that >> the vCPU to CPUState mapping could stay 1:1? >=20 > s390 hardware today already has a topology and CPU features. We are no= t=20 > modelling it in QEMU right now, but want to go there in the future so t= hat=20 > there would be no simple 1:1 mapping anymore. In that case please enlighten us how the topology model should/could look like in the future, so that we can align this with the x86 remodelling and APIC/ID discussion. Regards, Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg