From: Zhao Liu <zhao1.liu@linux.intel.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>
Cc: "Eduardo Habkost" <eduardo@habkost.net>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>,
"Yanan Wang" <wangyanan55@huawei.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Eric Blake" <eblake@redhat.com>,
"Markus Armbruster" <armbru@redhat.com>,
"Marcelo Tosatti" <mtosatti@redhat.com>,
"Daniel P . Berrangé" <berrange@redhat.com>,
qemu-devel@nongnu.org, kvm@vger.kernel.org,
"Zhenyu Wang" <zhenyu.z.wang@intel.com>,
"Zhuocheng Ding" <zhuocheng.ding@intel.com>,
"Babu Moger" <babu.moger@amd.com>,
"Yongwei Ma" <yongwei.ma@intel.com>,
"Zhao Liu" <zhao1.liu@intel.com>
Subject: Re: [PATCH v9 11/21] i386/cpu: Decouple CPUID[0x1F] subleaf with specific topology level
Date: Tue, 12 Mar 2024 18:11:24 +0800 [thread overview]
Message-ID: <ZfAqTEN8pvvgZ8IO@intel.com> (raw)
In-Reply-To: <005c1649-43d3-494f-951a-166e7200ffd5@intel.com>
On Mon, Mar 11, 2024 at 04:45:41PM +0800, Xiaoyao Li wrote:
> Date: Mon, 11 Mar 2024 16:45:41 +0800
> From: Xiaoyao Li <xiaoyao.li@intel.com>
> Subject: Re: [PATCH v9 11/21] i386/cpu: Decouple CPUID[0x1F] subleaf with
> specific topology level
>
> On 2/27/2024 6:32 PM, Zhao Liu wrote:
> > From: Zhao Liu <zhao1.liu@intel.com>
> >
> > At present, the subleaf 0x02 of CPUID[0x1F] is bound to the "die" level.
> >
> > In fact, the specific topology level exposed in 0x1F depends on the
> > platform's support for extension levels (module, tile and die).
> >
> > To help expose "module" level in 0x1F, decouple CPUID[0x1F] subleaf
> > with specific topology level.
> >
> > Tested-by: Yongwei Ma <yongwei.ma@intel.com>
> > Signed-off-by: Zhao Liu <zhao1.liu@intel.com>
>
> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com>
Thanks!
> Besides, some nits below.
>
[snip]
> > +static void encode_topo_cpuid1f(CPUX86State *env, uint32_t count,
> > + X86CPUTopoInfo *topo_info,
> > + uint32_t *eax, uint32_t *ebx,
> > + uint32_t *ecx, uint32_t *edx)
> > +{
> > + X86CPU *cpu = env_archcpu(env);
> > + unsigned long level;
> > + uint32_t num_threads_next_level, offset_next_level;
> > +
> > + assert(count + 1 < CPU_TOPO_LEVEL_MAX);
> > +
> > + /*
> > + * Find the No.count topology levels in avail_cpu_topo bitmap.
> > + * Start from bit 0 (CPU_TOPO_LEVEL_INVALID).
>
> AFAICS, it starts from bit 1 (CPU_TOPO_LEVEL_SMT). Because the initial value
> of level is CPU_TOPO_LEVEL_INVALID, but the first round of the loop is to
> find the valid bit starting from (level + 1).
Yes, this description is much clearer.
> > + */
> > + level = CPU_TOPO_LEVEL_INVALID;
> > + for (int i = 0; i <= count; i++) {
> > + level = find_next_bit(env->avail_cpu_topo,
> > + CPU_TOPO_LEVEL_PACKAGE,
> > + level + 1);
> > +
> > + /*
> > + * CPUID[0x1f] doesn't explicitly encode the package level,
> > + * and it just encode the invalid level (all fields are 0)
> > + * into the last subleaf of 0x1f.
> > + */
>
> QEMU will never set bit CPU_TOPO_LEVEL_PACKAGE in env->avail_cpu_topo.
In the patch 9 [1], I set the CPU_TOPO_LEVEL_PACKAGE in bitmap. This
level is a basic topology level in general, so it's worth being set.
Only in Intel's 0x1F, it doesn't have a corresponding type, and where
I use it as a termination condition for 0x1F encoding (not an error case).
[1]: https://lore.kernel.org/qemu-devel/20240227103231.1556302-10-zhao1.liu@linux.intel.com/
> So I think we should assert() it instead of fixing it silently.
>
> > + if (level == CPU_TOPO_LEVEL_PACKAGE) {
> > + level = CPU_TOPO_LEVEL_INVALID;
> > + break;
> > + }
> > + }
> > +
> > + if (level == CPU_TOPO_LEVEL_INVALID) {
> > + num_threads_next_level = 0;
> > + offset_next_level = 0;
> > + } else {
> > + unsigned long next_level;
>
> please define it at the beginning of the function. e.g.,
Okay, I'll put the declaration of "next_level" at the beginning of this
function with a current variable "level".
>
> > + next_level = find_next_bit(env->avail_cpu_topo,
> > + CPU_TOPO_LEVEL_PACKAGE,
> > + level + 1);
> > + num_threads_next_level = num_threads_by_topo_level(topo_info,
> > + next_level);
> > + offset_next_level = apicid_offset_by_topo_level(topo_info,
> > + next_level);
> > + }
> > +
> > + *eax = offset_next_level;
> > + *ebx = num_threads_next_level;
> > + *ebx &= 0xffff; /* The count doesn't need to be reliable. */
>
> we can combine them together. e.g.,
>
> *ebx = num_threads_next_level & 0xffff; /* ... */
>
> > + *ecx = count & 0xff;
> > + *ecx |= cpuid1f_topo_type(level) << 8;
>
> Ditto,
>
> *ecx = count & 0xff | cpuid1f_topo_type(level) << 8;
OK, will combine these.
> > + *edx = cpu->apic_id;
> > +
> > + assert(!(*eax & ~0x1f));
> > +}
> > +
next prev parent reply other threads:[~2024-03-12 9:58 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-27 10:32 [PATCH v9 00/21] Introduce smp.modules for x86 in QEMU Zhao Liu
2024-02-27 10:32 ` [PATCH v9 01/21] hw/core/machine: Introduce the module as a CPU topology level Zhao Liu
2024-02-27 10:32 ` [PATCH v9 02/21] hw/core/machine: Support modules in -smp Zhao Liu
2024-02-28 9:56 ` Markus Armbruster
2024-03-11 10:22 ` Mi, Dapeng
2024-03-12 10:12 ` Zhao Liu
2024-02-27 10:32 ` [PATCH v9 03/21] hw/core: Introduce module-id as the topology subindex Zhao Liu
2024-02-28 9:57 ` Markus Armbruster
2024-02-27 10:32 ` [PATCH v9 04/21] hw/core: Support module-id in numa configuration Zhao Liu
2024-02-27 10:32 ` [PATCH v9 05/21] i386/cpu: Fix i/d-cache topology to core level for Intel CPU Zhao Liu
2024-02-27 10:32 ` [PATCH v9 06/21] i386/cpu: Use APIC ID info to encode cache topo in CPUID[4] Zhao Liu
2024-03-09 13:39 ` Xiaoyao Li
2024-03-10 13:38 ` Zhao Liu
2024-03-11 8:23 ` Zhao Liu
2024-03-11 9:03 ` Xiaoyao Li
2024-03-12 9:04 ` Zhao Liu
2024-02-27 10:32 ` [PATCH v9 07/21] i386/cpu: Use APIC ID info get NumSharingCache for CPUID[0x8000001D].EAX[bits 25:14] Zhao Liu
2024-02-29 15:13 ` Moger, Babu
2024-03-09 13:41 ` Xiaoyao Li
2024-02-27 10:32 ` [PATCH v9 08/21] i386/cpu: Consolidate the use of topo_info in cpu_x86_cpuid() Zhao Liu
2024-03-09 13:48 ` Xiaoyao Li
2024-03-10 13:44 ` Zhao Liu
2024-02-27 10:32 ` [PATCH v9 09/21] i386/cpu: Introduce bitmap to cache available CPU topology levels Zhao Liu
2024-03-11 6:28 ` Xiaoyao Li
2024-03-11 8:19 ` Zhao Liu
2024-02-27 10:32 ` [PATCH v9 10/21] i386: Split topology types of CPUID[0x1F] from the definitions of CPUID[0xB] Zhao Liu
2024-02-27 10:32 ` [PATCH v9 11/21] i386/cpu: Decouple CPUID[0x1F] subleaf with specific topology level Zhao Liu
2024-03-11 8:45 ` Xiaoyao Li
2024-03-12 10:11 ` Zhao Liu [this message]
2024-02-27 10:32 ` [PATCH v9 12/21] i386: Introduce module level cpu topology to CPUX86State Zhao Liu
2024-02-27 10:32 ` [PATCH v9 13/21] i386: Support modules_per_die in X86CPUTopoInfo Zhao Liu
2024-02-27 10:32 ` [PATCH v9 14/21] i386: Expose module level in CPUID[0x1F] Zhao Liu
2024-02-27 10:32 ` [PATCH v9 15/21] i386: Support module_id in X86CPUTopoIDs Zhao Liu
2024-02-27 10:32 ` [PATCH v9 16/21] i386/cpu: Introduce module-id to X86CPU Zhao Liu
2024-02-27 10:32 ` [PATCH v9 17/21] tests: Add test case of APIC ID for module level parsing Zhao Liu
2024-02-27 10:32 ` [PATCH v9 18/21] hw/i386/pc: Support smp.modules for x86 PC machine Zhao Liu
2024-02-28 21:22 ` Moger, Babu
2024-02-29 7:32 ` Zhao Liu
2024-02-29 15:11 ` Moger, Babu
2024-03-01 6:27 ` Zhao Liu
2024-02-27 10:32 ` [PATCH v9 19/21] i386: Add cache topology info in CPUCacheInfo Zhao Liu
2024-02-27 10:32 ` [PATCH v9 20/21] i386/cpu: Use CPUCacheInfo.share_level to encode CPUID[4] Zhao Liu
2024-02-27 10:32 ` [PATCH v9 21/21] i386/cpu: Use CPUCacheInfo.share_level to encode CPUID[0x8000001D].EAX[bits 25:14] Zhao Liu
2024-02-29 15:11 ` Moger, Babu
2024-02-27 10:41 ` [PATCH v9 00/21] Introduce smp.modules for x86 in QEMU Zhao Liu
2024-03-08 15:20 ` Zhao Liu
2024-02-29 15:14 ` Moger, Babu
2024-03-08 16:36 ` Philippe Mathieu-Daudé
2024-03-09 0:49 ` Zhao Liu
2024-03-09 13:55 ` Philippe Mathieu-Daudé
2024-03-10 13:06 ` Zhao Liu
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=ZfAqTEN8pvvgZ8IO@intel.com \
--to=zhao1.liu@linux.intel.com \
--cc=armbru@redhat.com \
--cc=babu.moger@amd.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=eduardo@habkost.net \
--cc=kvm@vger.kernel.org \
--cc=marcel.apfelbaum@gmail.com \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=wangyanan55@huawei.com \
--cc=xiaoyao.li@intel.com \
--cc=yongwei.ma@intel.com \
--cc=zhao1.liu@intel.com \
--cc=zhenyu.z.wang@intel.com \
--cc=zhuocheng.ding@intel.com \
/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).