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

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

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 (jjherne@linux.vnet.ibm.com)