From: Zhao Liu <zhao1.liu@intel.com>
To: Xiaoyao Li <xiaoyao.li@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Michael Rolnik <mrolnik@gmail.com>,
Brian Cain <bcain@quicinc.com>, Song Gao <gaosong@loongson.cn>,
Laurent Vivier <laurent@vivier.eu>,
"Edgar E. Iglesias" <edgar.iglesias@gmail.com>,
Aurelien Jarno <aurelien@aurel32.net>,
Palmer Dabbelt <palmer@dabbelt.com>,
Alistair Francis <alistair.francis@wdc.com>,
Bin Meng <bmeng.cn@gmail.com>, Thomas Huth <thuth@redhat.com>,
David Hildenbrand <david@redhat.com>,
Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>,
Artyom Tarasenko <atar4qemu@gmail.com>,
Bastian Koppelmann <kbastian@mail.uni-paderborn.de>,
Max Filippov <jcmvbkbc@gmail.com>,
qemu-devel@nongnu.org
Subject: Re: [PATCH v1 0/4] Initialize nr_cores and nr_threads early and related clearup
Date: Thu, 5 Dec 2024 15:30:45 +0800 [thread overview]
Message-ID: <Z1FWpU36ZleXn7c4@intel.com> (raw)
In-Reply-To: <20241108070609.3653085-1-xiaoyao.li@intel.com>
I'm also very sorry, but I have a slightly different opinion...
> accel/tcg/user-exec-stub.c | 4 +++
> hw/core/cpu-common.c | 2 +-
> include/hw/core/cpu.h | 8 +++++
> system/cpus.c | 6 +++-
> target/alpha/cpu.c | 2 ++
> target/arm/cpu.c | 2 ++
> target/avr/cpu.c | 2 ++
> target/hexagon/cpu.c | 2 ++
> target/hppa/cpu.c | 2 ++
> target/i386/cpu.c | 61 +++++++++++++++++++-------------------
> target/loongarch/cpu.c | 2 ++
> target/m68k/cpu.c | 2 ++
> target/microblaze/cpu.c | 2 ++
> target/mips/cpu.c | 2 ++
> target/openrisc/cpu.c | 2 ++
> target/ppc/cpu_init.c | 2 ++
> target/riscv/cpu.c | 2 ++
> target/rx/cpu.c | 2 ++
> target/s390x/cpu.c | 2 ++
> target/sh4/cpu.c | 2 ++
> target/sparc/cpu.c | 2 ++
> target/tricore/cpu.c | 2 ++
> target/xtensa/cpu.c | 2 ++
> 23 files changed, 85 insertions(+), 32 deletions(-)
>
I have some doubts about the necessity of changing the initialization of
nr_cores/nr_threads, because you can access the machine's topology info
via machine_topo_get_threads_per_socket(), which gives the same result as
`nr_cores * nr_threads`.
Especially, the TDX feature check hook is also within the context of
`current_machine`, so why not check if TDX's HT is consistent with QEMU's
emulation in the TDX hook?
For this reason, and based on my comment on patch 2, I think checking HT
in the TDX hook or even ignoring HT, would be a more straightforward and
less impactful solution.
-Zhao
next prev parent reply other threads:[~2024-12-05 7:13 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-08 7:06 [PATCH v1 0/4] Initialize nr_cores and nr_threads early and related clearup Xiaoyao Li
2024-11-08 7:06 ` [PATCH v1 1/4] cpu: Introduce qemu_early_init_vcpu() to initialize nr_cores and nr_threads inside it Xiaoyao Li
2024-11-22 16:03 ` [PATCH] cpu: Initialize nr_cores and nr_threads in cpu_common_initfn() Xiaoyao Li
2024-11-22 17:26 ` Philippe Mathieu-Daudé
2024-11-22 19:17 ` Richard Henderson
2024-11-25 9:38 ` Igor Mammedov
2024-11-29 7:12 ` Xiaoyao Li
2024-12-05 11:53 ` Xiaoyao Li
2024-11-08 7:06 ` [PATCH v1 2/4] i386/cpu: Set up CPUID_HT in x86_cpu_expand_features() instead of cpu_x86_cpuid() Xiaoyao Li
2024-12-05 7:19 ` Zhao Liu
2024-12-05 7:54 ` Xiaoyao Li
2024-12-05 8:31 ` Zhao Liu
2024-12-05 8:34 ` Xiaoyao Li
2024-11-08 7:06 ` [PATCH v1 3/4] i386/cpu: Set and track CPUID_EXT3_CMP_LEG in env->features[FEAT_8000_0001_ECX] Xiaoyao Li
2024-11-08 7:06 ` [PATCH v1 4/4] i386/cpu: Rectify the comment on order dependency on qemu_init_vcpu() Xiaoyao Li
2024-11-11 10:49 ` [PATCH v1 0/4] Initialize nr_cores and nr_threads early and related clearup David Hildenbrand
2024-11-21 16:24 ` Xiaoyao Li
2024-11-21 17:39 ` Philippe Mathieu-Daudé
2024-11-21 18:52 ` Paolo Bonzini
2024-11-22 2:40 ` Xiaoyao Li
2024-11-22 9:44 ` David Hildenbrand
2024-11-22 9:53 ` Paolo Bonzini
2024-12-05 7:30 ` Zhao Liu [this message]
2024-12-05 8:05 ` Xiaoyao Li
2024-12-05 8:48 ` Zhao Liu
2024-12-05 8:50 ` Xiaoyao Li
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=Z1FWpU36ZleXn7c4@intel.com \
--to=zhao1.liu@intel.com \
--cc=alistair.francis@wdc.com \
--cc=atar4qemu@gmail.com \
--cc=aurelien@aurel32.net \
--cc=bcain@quicinc.com \
--cc=bmeng.cn@gmail.com \
--cc=david@redhat.com \
--cc=edgar.iglesias@gmail.com \
--cc=gaosong@loongson.cn \
--cc=jcmvbkbc@gmail.com \
--cc=kbastian@mail.uni-paderborn.de \
--cc=laurent@vivier.eu \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=mrolnik@gmail.com \
--cc=palmer@dabbelt.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
--cc=xiaoyao.li@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.