As we know, die is a rectangular piece of a semiconductor wafer. It's very common
that chip manufacturers put a multi-core die in one package and one die always has
a one-to-one relationship with one socket. Inside the die, it cotains multi-cores
and core contains threads topologically. We apply this socket/core/thread model to
the qemu -smp configurable space and save it into APIC_IDs for identification.

The undercurrent Is surging. Multi-chip packaging technology allows for integration
of multi-die devices in a single package, for example Intel CLX-AP or AMD EPYC.
Integration can be enabled by high-performance, heterogeneous, multi-dies interconnect
technology, providing a more cost-effective manner. QEMU and guests may take advantages
of multi-dies host for such as guest placing or energy efficiency management...

This patch series extend the CPU topology to the socket/dies/core/thread model,
allowing the setting of dies number per one socket on -smp qemu command. For
i386, it upgrades APIC_IDs generation and reversion functions with a new exposed
leaf called CPUID.1F, which is a preferred superset to leaf 0BH. The CPUID.1F
spec is on https://software.intel.com/en-us/articles/intel-sdm, 3-190 Vol 2A.

E.g. we use -smp 4,dies=2,cores=2,threads=1 to run an MCP kvm-guest,
check raw cpuid data and the expected output from guest is following:
0x0000001f 0x00: eax=0x00000000 ebx=0x00000001 ecx=0x00000100 edx=0x00000002
0x0000001f 0x01: eax=0x00000001 ebx=0x00000002 ecx=0x00000201 edx=0x00000001
0x0000001f 0x02: eax=0x00000002 ebx=0x00000004 ecx=0x00000502 edx=0x00000003
0x0000001f 0x03: eax=0x00000000 ebx=0x00000000 ecx=0x00000003 edx=0x00000001

Like Xu (5):
  cpu: introduce die, the new cpu toppolgy emulation level
  vl.c: add -smp,dies=* command line support
  i386: extend x86_apicid_* functions for smp_dies support
  i386: enable CPUID.1F leaf generation based on spec
  i386: add CPUID.1F to cpuid_data with host_cpuid check

 cpus.c                     |  1 +
 hmp.c                      |  3 ++
 hw/core/machine.c          | 12 +++++++
 hw/i386/pc.c               | 37 +++++++++++++++-------
 include/hw/i386/topology.h | 79 ++++++++++++++++++++++++++++++++++------------
 include/qom/cpu.h          |  1 +
 include/sysemu/cpus.h      |  1 +
 qapi/misc.json             |  1 +
 target/i386/cpu.c          | 57 +++++++++++++++++++++++++++++----
 target/i386/cpu.h          |  5 +++
 target/i386/kvm.c          | 34 +++++++++++++++++++-
 target/i386/kvm_i386.h     |  1 +
 vl.c                       | 33 +++++++++++--------
 13 files changed, 213 insertions(+), 52 deletions(-)

-- 
1.8.3.1

On Mon, 14 Jan 2019 20:24:54 +0800
Like Xu <like.xu@linux.intel.com> wrote:

> As we know, die is a rectangular piece of a semiconductor wafer. It's very common
> that chip manufacturers put a multi-core die in one package and one die always has
> a one-to-one relationship with one socket. Inside the die, it cotains multi-cores
> and core contains threads topologically. We apply this socket/core/thread model to
> the qemu -smp configurable space and save it into APIC_IDs for identification.
> 
> The undercurrent Is surging. Multi-chip packaging technology allows for integration
> of multi-die devices in a single package, for example Intel CLX-AP or AMD EPYC.
> Integration can be enabled by high-performance, heterogeneous, multi-dies interconnect
> technology, providing a more cost-effective manner. QEMU and guests may take advantages
> of multi-dies host for such as guest placing or energy efficiency management...
> 
> This patch series extend the CPU topology to the socket/dies/core/thread model,
> allowing the setting of dies number per one socket on -smp qemu command. For
> i386, it upgrades APIC_IDs generation and reversion functions with a new exposed
> leaf called CPUID.1F, which is a preferred superset to leaf 0BH. The CPUID.1F
> spec is on https://software.intel.com/en-us/articles/intel-sdm, 3-190 Vol 2A.

Looked into discussion within this mail thread, so here is my thoughts
on mentioned issues:

 * I agree with Daniel on the point that "-smp cores" should change 'cores'
   meaning to cores within die when die is used.
 * I dislike extending smp_parse() though and adding one more global,
   as it just adds up more mess to topology thingy QEMU has and puts
   an additional burden on whoever comes later to make it right.
   After talking with Eduardo, I think it's reasonable to refactor
   smp_parse() into machine properties first before adding 'dies',
   i.e. 'dies' and the rest of '-smp' should be implemented as machine
   properties where 'cpu_dies' is PCMachine specific property.
   If it ever becomes useful for other machines we can move common code up
   hierarchy to the generic Machine object later and let machine versions take
   care of compat issues if any (which is not possible with generic smp_parse()).
   So I'd suggest to:
      1: make existing cores/threads/sockets into machine properties and
         get rid of global variables they use currently
      2: #1 should make this trivial: add 'cpu_dies' to PCMachine and
         an optional CpuInstanceProperties::die-id with necessary generic glue
         where it's necessary.
         * for 'cpu_dies', we may use 0 (default) to make old machines work as they
           used to (i.e. not reporting dies existence) and new machines could
           enable/require dies by default or on request. In this case it should
           not cause any migration/hotplug issues.

On 2019/1/17 22:24, Igor Mammedov wrote:
> On Mon, 14 Jan 2019 20:24:54 +0800
> Like Xu <like.xu@linux.intel.com> wrote:
> 
>> As we know, die is a rectangular piece of a semiconductor wafer. It's very common
>> that chip manufacturers put a multi-core die in one package and one die always has
>> a one-to-one relationship with one socket. Inside the die, it cotains multi-cores
>> and core contains threads topologically. We apply this socket/core/thread model to
>> the qemu -smp configurable space and save it into APIC_IDs for identification.
>>
>> The undercurrent Is surging. Multi-chip packaging technology allows for integration
>> of multi-die devices in a single package, for example Intel CLX-AP or AMD EPYC.
>> Integration can be enabled by high-performance, heterogeneous, multi-dies interconnect
>> technology, providing a more cost-effective manner. QEMU and guests may take advantages
>> of multi-dies host for such as guest placing or energy efficiency management...
>>
>> This patch series extend the CPU topology to the socket/dies/core/thread model,
>> allowing the setting of dies number per one socket on -smp qemu command. For
>> i386, it upgrades APIC_IDs generation and reversion functions with a new exposed
>> leaf called CPUID.1F, which is a preferred superset to leaf 0BH. The CPUID.1F
>> spec is on https://software.intel.com/en-us/articles/intel-sdm, 3-190 Vol 2A.
> 
> Looked into discussion within this mail thread, so here is my thoughts
> on mentioned issues:
> 
>   * I agree with Daniel on the point that "-smp cores" should change 'cores'
>     meaning to cores within die when die is used.
>   * I dislike extending smp_parse() though and adding one more global,
>     as it just adds up more mess to topology thingy QEMU has and puts
>     an additional burden on whoever comes later to make it right.
>     After talking with Eduardo, I think it's reasonable to refactor
>     smp_parse() into machine properties first before adding 'dies',
>     i.e. 'dies' and the rest of '-smp' should be implemented as machine
>     properties where 'cpu_dies' is PCMachine specific property.
>     If it ever becomes useful for other machines we can move common code up
>     hierarchy to the generic Machine object later and let machine versions take
>     care of compat issues if any (which is not possible with generic smp_parse()).
>     So I'd suggest to:
>        1: make existing cores/threads/sockets into machine properties and
>           get rid of global variables they use currently
>        2: #1 should make this trivial: add 'cpu_dies' to PCMachine and
>           an optional CpuInstanceProperties::die-id with necessary generic glue
>           where it's necessary.
>           * for 'cpu_dies', we may use 0 (default) to make old machines work as they
>             used to (i.e. not reporting dies existence) and new machines could
>             enable/require dies by default or on request. In this case it should
>             not cause any migration/hotplug issues.
> 
Hi Igor, thanks for your suggestions on machine properties.
Let me try this additional (RFC) work for the expandable cpu topo model.