From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abu4M-0006ji-Gy for qemu-devel@nongnu.org; Fri, 04 Mar 2016 13:03:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1abu4J-0000yT-6l for qemu-devel@nongnu.org; Fri, 04 Mar 2016 13:03:18 -0500 Received: from mx1.redhat.com ([209.132.183.28]:38812) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1abu4I-0000xw-Vy for qemu-devel@nongnu.org; Fri, 04 Mar 2016 13:03:15 -0500 Date: Fri, 4 Mar 2016 19:03:10 +0100 From: Igor Mammedov Message-ID: <20160304190310.397979bb@nial.brq.redhat.com> In-Reply-To: <20160304125005.6859b725@thinkpad-w530> 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> <20160304125005.6859b725@thinkpad-w530> 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: David Hildenbrand Cc: Matthew Rosato , agraf@suse.de, qemu-devel@nongnu.org, borntraeger@de.ibm.com, Bharata B Rao , cornelia.huck@de.ibm.com, pbonzini@redhat.com, afaerber@suse.de, rth@twiddle.net On Fri, 4 Mar 2016 12:50:05 +0100 David Hildenbrand wrote: > > 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). with device_add 'id' is not a vcpu concept but and arbitrary user supplied string property owned by Device. But since s390 matches current x86 thread based model it could be migrated to device_add the same way, for example: device_add s390-cpu,thread=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. for s390, the thing about not rewriting everything once again could be replacing places where cpu_index is used with CpuClass.arch_id(). arch_id() defaults to cpu_index but you can later override it with your own id (whatever s390 uses for identifying cpus on baremetal) so switching to device_add won't break anything. > > David >