Re: [Qemu-devel] [PATCH 5/8] [PATCH RFC v3] s390-qemu: cpu hotplug - ipi_states enhancements

["Jason J. Herne" <jjherne@linux.vnet.ibm.com>]

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" <jjherne@us.ibm.com>
>>
...
>
> 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.

I wrote the code, very close to how you suggested and it appears to be 
working when tested with qom-list.  I'm still not certain why we need 
the ability to set the opaque of object_set_link_property()?

For reference here is what I did:

void s390_init_cpus(const char *cpu_model)
{
     int i;
     char* name;

     if (cpu_model == NULL) {
         cpu_model = "host";
     }

     ipi_states = g_malloc0(sizeof(S390CPU *) * max_cpus);

     for (i = 0; i < max_cpus; i++) {
         name = g_strdup_printf("cpu[%i]", i);
         object_property_add_link(qdev_get_machine(), name, TYPE_S390_CPU,
                                  (Object **)&ipi_states[i], NULL);
     }

     for (i = 0; i < smp_cpus; i++) {
         cpu_s390x_init(cpu_model);
     }
}

Yep, I know cpu_model is going away ;).

-- 
-- Jason J. Herne (jjherne@linux.vnet.ibm.com)