From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:56168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gk94j-0004Aq-9Q for qemu-devel@nongnu.org; Thu, 17 Jan 2019 09:55:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gk918-0005Ml-Hy for qemu-devel@nongnu.org; Thu, 17 Jan 2019 09:51:39 -0500 Received: from mga03.intel.com ([134.134.136.65]:4016) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gk917-000539-9W for qemu-devel@nongnu.org; Thu, 17 Jan 2019 09:51:38 -0500 References: <1547468699-17633-1-git-send-email-like.xu@linux.intel.com> <20190117152444.16163014@redhat.com> From: Like Xu Message-ID: Date: Thu, 17 Jan 2019 22:51:18 +0800 MIME-Version: 1.0 In-Reply-To: <20190117152444.16163014@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v1 0/5] Introduce cpu die topology and enable CPUID.1F for i386 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Igor Mammedov Cc: qemu-devel@nongnu.org, drjones@redhat.com, Peter Crosthwaite , Eduardo Habkost , "Michael S. Tsirkin" , like.xu@intel.com, Marcelo Tosatti , Paolo Bonzini , Richard Henderson On 2019/1/17 22:24, Igor Mammedov wrote: > On Mon, 14 Jan 2019 20:24:54 +0800 > Like Xu 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.