qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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));
> > +}
> > +


  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).