From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:32902) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abna8-00025v-Te for qemu-devel@nongnu.org; Fri, 04 Mar 2016 06:07:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1abna6-0000rN-7c for qemu-devel@nongnu.org; Fri, 04 Mar 2016 06:07:40 -0500 Received: from e06smtp13.uk.ibm.com ([195.75.94.109]:44036) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abna5-0000rI-TQ for qemu-devel@nongnu.org; Fri, 04 Mar 2016 06:07:38 -0500 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 4 Mar 2016 11:07:36 -0000 Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id C4DA1219005C for ; Fri, 4 Mar 2016 11:07:16 +0000 (GMT) Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u24B7XjG6881646 for ; Fri, 4 Mar 2016 11:07:33 GMT Received: from d06av06.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u24B7Wew025962 for ; Fri, 4 Mar 2016 06:07:33 -0500 Date: Fri, 4 Mar 2016 12:07:28 +0100 From: David Hildenbrand Message-ID: <20160304120728.0df50c1e@thinkpad-w530> In-Reply-To: <20160304101622.GA5054@in.ibm.com> References: <1457040633-30951-1-git-send-email-mjrosato@linux.vnet.ibm.com> <1457040633-30951-7-git-send-email-mjrosato@linux.vnet.ibm.com> <20160304101622.GA5054@in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v8 6/7] s390x/cpu: Add error handling to cpu creation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bharata B Rao Cc: Matthew Rosato , qemu-devel@nongnu.org, agraf@suse.de, borntraeger@de.ibm.com, imammedo@redhat.com, cornelia.huck@de.ibm.com, pbonzini@redhat.com, afaerber@suse.de, rth@twiddle.net > > cpu_exec_init(cs, &err); > > if (err != NULL) { > > error_propagate(errp, err); > > return; > > } > > + scc->next_cpu_id = cs->cpu_index + 1; > > It appears that scc->next_cpu_id (and hence cpu->id) is some sort of arch_id > for you. If it is just going to be monotonically increasing like cs->cpu_index, > couldn't you just use cs->cpu_index instead of introducing additional IDs ? > > Note that cpu_exec_init(cs, &err) returns with the next available cpu_index > which can be compared against max_cpus directly. > > Regards, > Bharata. I don't think that we should mix the id setting and cpu_index for now. We can't simply set cpu_index before the device is realized. That logic belongs to cpu_exec_init(). But I agree that cpu_index and id should always match after a successful realize. That id / cpu_index stuff can be cleaned up later. We should not treat cpu_index as a property for now (by exposing it as "id"). David