[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v1 0/5] Introduce cpu die topology and enable CP

From: Like Xu
Subject: Re: [Qemu-devel] [PATCH v1 0/5] Introduce cpu die topology and enable CPUID.1F for i386
Date: Thu, 17 Jan 2019 22:51:18 +0800
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 2019/1/17 22:24, Igor Mammedov wrote:
On Mon, 14 Jan 2019 20:24:54 +0800
Like Xu <address@hidden> wrote:

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

The undercurrent Is surging. Multi-chip packaging technology allows for 
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 
technology, providing a more cost-effective manner. QEMU and guests may take 
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 
    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 
            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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]