From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VN3g7-0004YW-Tc for qemu-devel@nongnu.org; Fri, 20 Sep 2013 12:35:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VN3fx-0001vR-CR for qemu-devel@nongnu.org; Fri, 20 Sep 2013 12:35:35 -0400 Received: from e06smtp14.uk.ibm.com ([195.75.94.110]:50489) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VN3fx-0001ut-3d for qemu-devel@nongnu.org; Fri, 20 Sep 2013 12:35:25 -0400 Received: from /spool/local by e06smtp14.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 20 Sep 2013 17:35:23 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (d06relay13.portsmouth.uk.ibm.com [9.149.109.198]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id 3B35B17D8058 for ; Fri, 20 Sep 2013 17:35:32 +0100 (BST) Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com [9.149.37.252]) by b06cxnps4076.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r8KGZ8M657409708 for ; Fri, 20 Sep 2013 16:35:08 GMT Received: from d06av11.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r8KGZJIT023567 for ; Fri, 20 Sep 2013 10:35:20 -0600 Date: Fri, 20 Sep 2013 18:35:17 +0200 From: Michael Mueller Message-ID: <20130920183517.4219a453@bee> In-Reply-To: <523B5C62.4050804@linux.vnet.ibm.com> References: <1375366359-11553-1-git-send-email-jjherne@us.ibm.com> <1375366359-11553-6-git-send-email-jjherne@us.ibm.com> <522872B6.5080705@suse.de> <523B5C62.4050804@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 5/8] [PATCH RFC v3] s390-qemu: cpu hotplug - ipi_states enhancements List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: jjherne@linux.vnet.ibm.com Cc: ehabkost@redhat.com, qemu-devel@nongnu.org, agraf@suse.de, borntraeger@de.ibm.com, jfrei@linux.vnet.ibm.com, Anthony Liguori , Paolo Bonzini , imammedo@redhat.com, "Jason J. Herne" , Andreas =?UTF-8?B?RsOkcmJlcg==?= On Thu, 19 Sep 2013 16:19:46 -0400 "Jason J. Herne" wrote: > On 09/05/2013 08:01 AM, Andreas F=C3=A4rber wrote: > > Am 01.08.2013 16:12, schrieb Jason J. Herne: > >> From: "Jason J. Herne" > >> > ... > > > > This is what got us into the link<> discussion last time. If we do > > > > for (i =3D 0; i < ARRAY_SIZE(ipi_states); i++) { > > name =3D g_strdup_printf("cpu[%i]", i); > > object_property_add_link(qdev_get_machine(), name, TYPE_S390_CPU, > > &ipi_states[i], &err); > > } > > > > then we get said /machine/cpu[n] link<> properties, at a QMP level > > either returning nothing or the canonical path to the CPU object. > > > > On IRC I didn't get an answer of whether it was being done the above way > > because there is infrastructure missing, and a look at object.h now > > confirms that suspicion. CC'ing Anthony and Paolo. > > > > Since object_property_add_link() uses a NULL opaque, my idea would be to > > add a single setter hook argument passed through as opaque to > > object_set_link_property(), which would call it with the old and the new > > value. > > > > The purpose would be to avoid growing our own internal setter API, which > > is disjoint from the QMP qom-set we are targetting at. >=20 > I wrote the code, very close to how you suggested and it appears to be=20 > working when tested with qom-list. I'm still not certain why we need=20 > the ability to set the opaque of object_set_link_property()? >=20 > For reference here is what I did: >=20 > void s390_init_cpus(const char *cpu_model) > { > int i; > char* name; >=20 > if (cpu_model =3D=3D NULL) { > cpu_model =3D "host"; > } >=20 > ipi_states =3D g_malloc0(sizeof(S390CPU *) * max_cpus); >=20 > for (i =3D 0; i < max_cpus; i++) { > name =3D g_strdup_printf("cpu[%i]", i); > object_property_add_link(qdev_get_machine(), name, TYPE_S390_CPU, > (Object **)&ipi_states[i], NULL); > } >=20 > for (i =3D 0; i < smp_cpus; i++) { > cpu_s390x_init(cpu_model); > } > } >=20 > Yep, I know cpu_model is going away ;). Jason, do you have more information how cpu modeling or at least the parame= terization will be managed in future? I'm close to finishing a patch that introduces S390 cpu = models and need to know all this more precisely. Is there any document or discussion you can p= oint me to. Thanks a lot. Michael=20 >=20