diff options
author | David Hildenbrand <david@redhat.com> | 2017-09-13 15:24:08 +0200 |
---|---|---|
committer | Cornelia Huck <cohuck@redhat.com> | 2017-09-19 18:31:32 +0200 |
commit | ca5c1457d614fec718aaec7bdf3663dec37e1e50 (patch) | |
tree | 9a51cf2ee8daeb424bf70f5a34218609a055fd66 /replay | |
parent | 88556edd74c82c7bb966f0e64d400f2ac898108d (diff) |
target/s390x: use "core-id" for cpu number/address/id handling
Some time ago we discussed that using "id" as property name is not the
right thing to do, as it is a reserved property for other devices and
will not work with device_add.
Switch to the term "core-id" instead, and use it as an equivalent to
"CPU address" mentioned in the PoP. There is no such thing as cpu number,
so rename env.cpu_num to env.core_id. We use "core-id" as this is the
common term to use for device_add later on (x86 and ppc).
We can get rid of cpu->id now. Keep cpu_index and env->core_id in sync.
cpu_index was already implicitly used by e.g. cpu_exists(), so keeping
both in sync seems to be the right thing to do.
cpu_index will now no longer automatically get set via
cpu_exec_realizefn(). For now, we were lucky that both implicitly stayed
in sync.
Our new cpu property "core-id" can be a static property. Range checks can
be avoided by using the correct type and the "setting after realized"
check is done implicitly.
device_add will later need the reserved "id" property. Hotplugging a CPU
on s390x will then be: "device_add host-s390-cpu,id=cpu2,core-id=2".
Reviewed-by: Matthew Rosato <mjrosato@linux.vnet.ibm.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
Message-Id: <20170913132417.24384-14-david@redhat.com>
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
Diffstat (limited to 'replay')
0 files changed, 0 insertions, 0 deletions