qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Michael Mueller
Subject: Re: [Qemu-devel] [PATCH 5/8] [PATCH RFC v3] s390-qemu: cpu hotplug - ipi_states enhancements
Date: Fri, 20 Sep 2013 18:35:17 +0200

On Thu, 19 Sep 2013 16:19:46 -0400
"Jason J. Herne" <address@hidden> wrote:

> 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" <address@hidden>
> >>
> ...
> >
> > 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, do you have more information how cpu modeling or at least the 
parameterization 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 point 
me to. Thanks a
lot.

Michael 

> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]