1. 09 2月, 2018 1 次提交
  2. 22 1月, 2018 1 次提交
  3. 30 12月, 2017 1 次提交
  4. 15 12月, 2017 16 次提交
  5. 09 11月, 2017 1 次提交
  6. 25 10月, 2017 5 次提交
  7. 20 10月, 2017 3 次提交
  8. 10 10月, 2017 1 次提交
  9. 06 10月, 2017 4 次提交
  10. 20 9月, 2017 1 次提交
    • D
      target/s390x: use "core-id" for cpu number/address/id handling · ca5c1457
      David Hildenbrand 提交于
      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: NMatthew Rosato <mjrosato@linux.vnet.ibm.com>
      Signed-off-by: NDavid Hildenbrand <david@redhat.com>
      Message-Id: <20170913132417.24384-14-david@redhat.com>
      Signed-off-by: NCornelia Huck <cohuck@redhat.com>
      ca5c1457
  11. 06 9月, 2017 1 次提交
  12. 31 8月, 2017 1 次提交
  13. 25 7月, 2017 1 次提交
  14. 20 7月, 2017 1 次提交
  15. 18 7月, 2017 2 次提交