From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38419) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abnyL-0001SG-F5 for qemu-devel@nongnu.org; Fri, 04 Mar 2016 06:32:42 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1abnyG-0007OP-EQ for qemu-devel@nongnu.org; Fri, 04 Mar 2016 06:32:41 -0500 Received: from e23smtp02.au.ibm.com ([202.81.31.144]:33444) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abnyF-0007Mo-SI for qemu-devel@nongnu.org; Fri, 04 Mar 2016 06:32:36 -0500 Received: from localhost by e23smtp02.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 4 Mar 2016 21:32:32 +1000 Received: from d23relay10.au.ibm.com (d23relay10.au.ibm.com [9.190.26.77]) by d23dlp01.au.ibm.com (Postfix) with ESMTP id 120B32CE8054 for ; Fri, 4 Mar 2016 22:32:30 +1100 (EST) Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay10.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u24BWLCU4718972 for ; Fri, 4 Mar 2016 22:32:30 +1100 Received: from d23av02.au.ibm.com (localhost [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u24BVuE5020218 for ; Fri, 4 Mar 2016 22:31:56 +1100 Date: Fri, 4 Mar 2016 17:01:29 +0530 From: Bharata B Rao Message-ID: <20160304113129.GC5054@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> <20160304120728.0df50c1e@thinkpad-w530> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160304120728.0df50c1e@thinkpad-w530> Subject: Re: [Qemu-devel] [PATCH v8 6/7] s390x/cpu: Add error handling to cpu creation Reply-To: bharata@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Hildenbrand 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 On Fri, Mar 04, 2016 at 12:07:28PM +0100, David Hildenbrand wrote: > > > > 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(). Yes, I see that, but apart from the following obvious uses of the id property from realizefn, are there other uses ? 1 Checking against max_cpus cpu_index can be used for this. 2 Checking if cpu with such an id exists cpu_exec_init() would never return with an in-use index. Hence cpu_index can be used here too given that you don't define ->get_arch_id() 3 Checking if the id is the next expected one cpu_exec_init/cpu_exec_exit take care of deletion too, so I guess you will always have the next available id to be used in cpu_index. Did I miss any other use other than these which makes it necessary to have an explicit id property here ? Regards, Bharata.