From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42873) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aboFi-0004EE-7F for qemu-devel@nongnu.org; Fri, 04 Mar 2016 06:50:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aboFe-0003UK-6b for qemu-devel@nongnu.org; Fri, 04 Mar 2016 06:50:38 -0500 Received: from e06smtp11.uk.ibm.com ([195.75.94.107]:32969) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aboFd-0003UG-US for qemu-devel@nongnu.org; Fri, 04 Mar 2016 06:50:34 -0500 Received: from localhost by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 4 Mar 2016 11:50:32 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id EFC1217D8042 for ; Fri, 4 Mar 2016 11:50:32 +0000 (GMT) Received: from d06av10.portsmouth.uk.ibm.com (d06av10.portsmouth.uk.ibm.com [9.149.37.251]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u24Bo7vY65142908 for ; Fri, 4 Mar 2016 11:50:07 GMT Received: from d06av10.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av10.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u24Ao8pg020743 for ; Fri, 4 Mar 2016 03:50:08 -0700 Date: Fri, 4 Mar 2016 12:50:05 +0100 From: David Hildenbrand Message-ID: <20160304125005.6859b725@thinkpad-w530> In-Reply-To: <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> <20160304113129.GC5054@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 > 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 ? After all the discussions about -device-add s390-cpu,id=XX As substitute/addition in the future for hotplug it is the straightforward approach to allow setting the id as property. Nobody knows what crazy new hotplug method we will come up with. But doing it the device way with properties cannot be wrong. And the id is a fundamental concept of a vcpu (cpu-add id=XX). So I'd like to avoid reworking everything again, to realize later that we want it as a property and rewriting it once again. David