qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v1 0/4] Initialize nr_cores and nr_threads early and related


From: Xiaoyao Li
Subject: Re: [PATCH v1 0/4] Initialize nr_cores and nr_threads early and related clearup
Date: Fri, 22 Nov 2024 00:24:58 +0800
User-agent: Mozilla Thunderbird

On 11/11/2024 6:49 PM, David Hildenbrand wrote:
On 08.11.24 08:06, Xiaoyao Li wrote:
This series is extracted from TDX QEMU v6[1] series per Paolo's request.

It is originally motivated by x86 TDX to track CPUID_HT in env- >features[]
which requires nr_cores and nr_cores being initialized earlier than in

"and nr_threads"

qemu_init_vcpu().

Initialize of nr_cores and nr_threads earlier in x86's cpu_realizefn()
can make it work for x86 but it's duplicated with the initialization in
qemu_init_vcpu() which are used by all the ARCHes. Since initialize them
earlier also work for other ARCHes, introduce qemu_init_early_vcpu() to
hold the initialization of nr_cores and nr_threads and call it at the
beginning in realizefn() for each ARCH.

Note, I only tested it for x86 ARCH. Please help test on other ARCHes.

[...]

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

Hm. It looks like this belongs into the parent realize function. But the "bad thing" is that we call the parent realize function after we try realizing the derived CPU.

Could it go into cpu_common_initfn()?


It can, I think.

I'll move them into cpu_common_initfn() in v2 to avoid touching all the ARCHes.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]