Re: [Qemu-devel] [PATCH 0/8] [PATCH RFC v3] s390 cpu hotplug

[Jason J. Herne]

On 09/05/2013 07:25 AM, Andreas Färber wrote:
> Am 05.09.2013 12:40, schrieb Christian Borntraeger:
> > On 04/09/13 14:45, Andreas Färber wrote:
...
> To cope with device_add s390-cpu adding the device to
> /machine/peripheral/<id> or /machine/peripheral-anon/device[0] I *think*
> we'll need link<>, which would then translate back to ipi_states array
> as backend and the remaining question would be where to expose those
> properties in the composition tree - i.e. /machine/cpu[n] or
> /machine/ipi/cpu[n] or something - please suggest. Similarly if those
> become link<> properties then the CPUs created by the machine via
> smp_cpus need a canonical path as well; quite obviously both cannot be
> the same.

Ok, if I understand right then /machine/peripheral[-anon]/device[n] is 
the canonical path given to a a cpu that is created via qdev_device_add. 
 We're going to create a link to that cpu via path 
/machine/cpu[cpu_addr].

I'm not sure what you meant by "if those become link<> properties then 
the CPUs created by the machine via smp_cpus need a canonical path as 
well".  Wouldn't the canonical path just be 
/machine/peripheral[-anon]/device[n]?  Are you saying we really want 
something different for non-hotplugged cpus?

> Background is that long-term Anthony would like x86 CPU hot-plug to
> become setting/unsetting some /machine/cpu-socket[n] link<> property of
> the machine, and the ipi_states array seems a close equivalent on s390x.
>
> > > => Guest unaware of any emulated topology today.
> >
> > An additional problem is, that for the normal case (linux scheduler, no 
> > pinning, also
> > no gang scheduling) the topology would change too fast. The guest would be busy 
> > rebuilding
> > the scheduler domains all the time.
> [snip]
>
> Regards,
> Andreas


--
-- Jason J. Herne (address@hidden)