From: Zhao Liu <zhao1.liu@intel.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>
Cc: Chuang Xu <xuchuangxclwt@bytedance.com>,
pbonzini@redhat.com, imammedo@redhat.com,
xieyongji@bytedance.com, chaiwen.cc@bytedance.com,
qemu-stable@nongnu.org, Guixiong Wei <weiguixiong@bytedance.com>,
Yipeng Yin <yinyipeng@bytedance.com>,
qemu-devel@nongnu.org
Subject: Re: [PATCH v6] i386/cpu: fixup number of addressable IDs for logical processors in the physical package
Date: Sat, 12 Oct 2024 16:56:08 +0800 [thread overview]
Message-ID: <Zwo5qH/TCNOQOXml@intel.com> (raw)
In-Reply-To: <cfa014eb-d658-4c53-aaf1-086baf22c52a@intel.com>
> > > > + if (cpu->vendor_cpuid_only && IS_AMD_CPU(env)) {
> > > > + *ebx |= threads_per_pkg << 16;
> > > > + } else {
> > > > + *ebx |= 1 << apicid_pkg_offset(&topo_info) << 16;
> > > > + }
> > >
> > > you need to handle the overflow case when the number of logical
> > > processors > 255.
> > >
> > It seems other cpuid cases of bit shifting don't condiser the overflow
> > case too..
> >
> > Since intel only reserves 8bits for this field, do you have any
> > suggestions to make sure this field emulated
> >
> > correctly?
>
> the usual option can be masking the value to only 8 bits before shifting,
> like
>
> ((1 << apicid_pkg_offset(&topo_info)) & 0xff) << 16
>
> but when the value is greater than 255, it will be truncated, so we need
> something like below to reflect the hardware behavior:
>
> MIN((1 << apicid_pkg_offset(&topo_info)), 255) << 16
>
> This is what Qian's patch [1] wanted to fix last year, but that patch never
> gets merged.
>
> [1] https://lore.kernel.org/qemu-devel/20230829042405.932523-2-qian.wen@intel.com/
>
That's on my list. I had the plan to help Qian pick up it again and
rebase that series on Chuang's change.
-Zhao
next prev parent reply other threads:[~2024-10-12 8:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-09 3:56 [PATCH v6] i386/cpu: fixup number of addressable IDs for logical processors in the physical package Chuang Xu
2024-10-09 4:21 ` Zhao Liu
2024-10-12 7:13 ` Xiaoyao Li
2024-10-12 8:10 ` Chuang Xu
2024-10-12 8:32 ` Xiaoyao Li
2024-10-12 8:56 ` Zhao Liu [this message]
2024-10-12 8:21 ` Xiaoyao Li
2024-10-12 9:28 ` Zhao Liu
2024-10-12 9:35 ` Chuang Xu
2024-10-14 0:36 ` Xiaoyao Li
2024-10-14 1:32 ` Xiaoyao Li
2024-10-14 3:36 ` Zhao Liu
2024-10-17 8:18 ` Xiaoyao Li
2024-10-17 9:03 ` Zhao Liu
2024-10-28 16:07 ` Xiaoyao Li
2024-12-03 7:33 ` Zhao Liu
2024-12-03 15:04 ` Xiaoyao Li
2024-12-03 15:35 ` Zhao Liu
2024-12-03 15:29 ` Daniel P. Berrangé
2024-12-03 7:36 ` Zhao Liu
2024-12-03 7:29 ` Chuang 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=Zwo5qH/TCNOQOXml@intel.com \
--to=zhao1.liu@intel.com \
--cc=chaiwen.cc@bytedance.com \
--cc=imammedo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
--cc=weiguixiong@bytedance.com \
--cc=xiaoyao.li@intel.com \
--cc=xieyongji@bytedance.com \
--cc=xuchuangxclwt@bytedance.com \
--cc=yinyipeng@bytedance.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).