From: Igor Mammedov <imammedo@redhat.com>
To: Like Xu <like.xu@linux.intel.com>
Cc: qemu-devel@nongnu.org, drjones@redhat.com,
Peter Crosthwaite <crosthwaite.peter@gmail.com>,
Eduardo Habkost <ehabkost@redhat.com>,
"Michael S. Tsirkin" <mst@redhat.com>,
like.xu@intel.com, Marcelo Tosatti <mtosatti@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v1 0/5] Introduce cpu die topology and enable CPUID.1F for i386
Date: Thu, 17 Jan 2019 15:24:44 +0100 [thread overview]
Message-ID: <20190117152444.16163014@redhat.com> (raw)
In-Reply-To: <1547468699-17633-1-git-send-email-like.xu@linux.intel.com>
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.
next prev parent reply other threads:[~2019-01-17 14:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-14 12:24 [Qemu-devel] [PATCH v1 0/5] Introduce cpu die topology and enable CPUID.1F for i386 Like Xu
2019-01-14 12:24 ` [Qemu-devel] [PATCH v1 1/5] cpu: introduce die, the new cpu toppolgy emulation level Like Xu
2019-01-14 20:08 ` Eric Blake
2019-01-15 1:34 ` Xu, Like
2019-01-14 12:24 ` [Qemu-devel] [PATCH v1 2/5] vl.c: add -smp, dies=* command line support Like Xu
2019-01-14 20:51 ` Eduardo Habkost
2019-01-15 3:58 ` Xu, Like
2019-01-16 18:26 ` Daniel P. Berrangé
2019-01-17 1:18 ` Like Xu
2019-01-17 9:53 ` Daniel P. Berrangé
2019-01-14 12:24 ` [Qemu-devel] [PATCH v1 3/5] i386: extend x86_apicid_* functions for smp_dies support Like Xu
2019-01-14 12:24 ` [Qemu-devel] [PATCH v1 4/5] i386: enable CPUID.1F leaf generation based on spec Like Xu
2019-01-14 12:24 ` [Qemu-devel] [PATCH v1 5/5] i386: add CPUID.1F to cpuid_data with host_cpuid check Like Xu
2019-01-17 14:24 ` Igor Mammedov [this message]
2019-01-17 14:51 ` [Qemu-devel] [PATCH v1 0/5] Introduce cpu die topology and enable CPUID.1F for i386 Like Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190117152444.16163014@redhat.com \
--to=imammedo@redhat.com \
--cc=crosthwaite.peter@gmail.com \
--cc=drjones@redhat.com \
--cc=ehabkost@redhat.com \
--cc=like.xu@intel.com \
--cc=like.xu@linux.intel.com \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).