From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38471) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKV8R-0008O5-N7 for qemu-devel@nongnu.org; Fri, 13 Sep 2013 11:18:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VKV8I-0007UN-Hz for qemu-devel@nongnu.org; Fri, 13 Sep 2013 11:18:15 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]:54990) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKV8I-0007UC-BY for qemu-devel@nongnu.org; Fri, 13 Sep 2013 11:18:06 -0400 Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 13 Sep 2013 09:18:05 -0600 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id B99421FF001E for ; Fri, 13 Sep 2013 09:18:00 -0600 (MDT) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r8DFHxKv361260 for ; Fri, 13 Sep 2013 09:17:59 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r8DFKvbZ007687 for ; Fri, 13 Sep 2013 09:20:57 -0600 Message-ID: <52332CA4.1080800@linux.vnet.ibm.com> Date: Fri, 13 Sep 2013 11:17:56 -0400 From: "Jason J. Herne" MIME-Version: 1.0 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> In-Reply-To: <522872B6.5080705@suse.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 5/8] [PATCH RFC v3] s390-qemu: cpu hotplug - ipi_states enhancements Reply-To: jjherne@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-15?Q?Andreas_F=E4rber?= Cc: ehabkost@redhat.com, qemu-devel@nongnu.org, agraf@suse.de, borntraeger@de.ibm.com, jfrei@linux.vnet.ibm.com, Anthony Liguori , imammedo@redhat.com, Paolo Bonzini , "Jason J. Herne" On 09/05/2013 08:01 AM, Andreas Färber wrote: > Am 01.08.2013 16:12, schrieb Jason J. Herne: >> From: "Jason J. Herne" >> >> Modify s390_cpu_addr2state to allow fetching state information for cpu addresses >> above smp_cpus. Hotplug requires this capability. >> >> Also add s390_cpu_set_state function to allow modification of ipi_state entries >> during hotplug. >> >> Signed-off-by: Jason J. Herne >> --- >> hw/s390x/s390-virtio.c | 9 +++++---- >> target-s390x/cpu.h | 2 +- >> 2 files changed, 6 insertions(+), 5 deletions(-) >> >> diff --git a/hw/s390x/s390-virtio.c b/hw/s390x/s390-virtio.c >> index 21e9124..5ad9cf3 100644 >> --- a/hw/s390x/s390-virtio.c >> +++ b/hw/s390x/s390-virtio.c >> @@ -54,12 +54,13 @@ >> static VirtIOS390Bus *s390_bus; >> static S390CPU **ipi_states; >> >> -S390CPU *s390_cpu_addr2state(uint16_t cpu_addr) >> +void s390_cpu_set_ipistate(uint16_t cpu_addr, S390CPU *state) >> { >> - if (cpu_addr >= smp_cpus) { >> - return NULL; >> - } >> + ipi_states[cpu_addr] = state; >> +} >> >> +S390CPU *s390_cpu_addr2state(uint16_t cpu_addr) >> +{ >> return ipi_states[cpu_addr]; >> } >> > > This is what got us into the link<> discussion last time. If we do > > for (i = 0; i < ARRAY_SIZE(ipi_states); i++) { > name = 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. > Ok, you lost me :). I must admit my understanding of QOM is still limited. Sorry for not keeping up. Why do we need this new hook? The link would contain a pointer to the correct ipi_states entry right? What are we using opaque for? -- -- Jason J. Herne (jjherne@linux.vnet.ibm.com)