From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58569) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHaCI-00011y-1Q for qemu-devel@nongnu.org; Thu, 05 Sep 2013 10:06:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHaCB-0006iD-Vc for qemu-devel@nongnu.org; Thu, 05 Sep 2013 10:06:09 -0400 Received: from cantor2.suse.de ([195.135.220.15]:44851 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHaCB-0006ht-LK for qemu-devel@nongnu.org; Thu, 05 Sep 2013 10:06:03 -0400 Message-ID: <52288FC8.7090200@suse.de> Date: Thu, 05 Sep 2013 16:06:00 +0200 From: =?ISO-8859-1?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1375366359-11553-1-git-send-email-jjherne@us.ibm.com> <0C872A4D-5B78-4F76-A254-41FDC3147896@suse.de> <522881AC.6030404@suse.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 0/8] [PATCH RFC v3] s390 cpu hotplug List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: ehabkost@redhat.com, qemu-devel@nongnu.org, "Jason J. Herne" , borntraeger@de.ibm.com, jfrei@linux.vnet.ibm.com, imammedo@redhat.com Am 05.09.2013 15:10, schrieb Alexander Graf: > On 05.09.2013, at 15:05, Andreas F=E4rber wrote: >> Am 05.09.2013 14:54, schrieb Alexander Graf: >>> Very simple and clean patch set. I don't think it deserves the RFC ta= g. >> >> Negative, see my review. If you want to fix up and queue patches 1-2 >> that's fine with me, but the others need a respin. No major blocker >> though, just some more footwork mostly related to QOM and Jason's >> shifted focus on cpu-add rather than device_add. >=20 > Yeah, that's what I'm referring to. I've seen a lot worse patch sets at= v8 than this RFC :). >=20 > I don't think we should apply it as is, and I'm very happy to see your = review and comment on the modeling bits :). But I try to never apply or c= herry pick RFC patches - and this set looks like he sent it with the inte= nt of getting it merged. Agreed, we can continue with "PATCH v4". I was more upset about the "very simple and clean" bit after I commented on a number of unclean things to improve - mostly about doing things in different places. If you could find some time to review my two model string patches then I could supply Jason with a branch or even a pull to base on: http://patchwork.ozlabs.org/patch/272511/ http://patchwork.ozlabs.org/patch/272509/ I would also volunteer to provide a base patch for the link<> issue if there is agreement. Apart from the QOM API question this depends on the contradictory modelling of whether we allow CPU addresses 0..max_cpus as seen in this series or 0..somemax with <=3D max_cpus non-NULL as discusse= d on #zkvm. (child properties would allow to model the latter sparse address space very well, but an object can only have one parent in the hot-add case. We could of course add cpu[n] link properties as CPUs get added, but that doesn't strike me as very clean. My underlying thought is to offload the error handling to QOM so that we don't start hardcoding s/smp_cpus/max_cpus/g (or some max_cpu_address) all around ipi_states.) Btw an unanswered question: ipi_states is just pointers to CPUs currently, no further state. So what's "ipi" in the name? Will that array need to carry state beyond S390CPU someday? 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