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