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(-)
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
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.
The following patch 2 - 4 are x86 specific.
[1] https://lore.kernel.org/qemu-devel/CABgObfZVxaQL4FSJX396kAJ67Qp=XhEWwcmv+NQZCbdpfbV9xg@mail.gmail.com/
Xiaoyao Li (4):
cpu: Introduce qemu_early_init_vcpu() to initialize nr_cores and
nr_threads inside it
i386/cpu: Set up CPUID_HT in x86_cpu_expand_features() instead of
cpu_x86_cpuid()
i386/cpu: Set and track CPUID_EXT3_CMP_LEG in
env->features[FEAT_8000_0001_ECX]
i386/cpu: Rectify the comment on order dependency on qemu_init_vcpu()
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(-)
--
2.34.1
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
On 12/5/2024 3:30 PM, Zhao Liu wrote: > 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`. yeah, it works. The goal is to maintain HT in env->features[]. The problem is, as Igor objects, accessing MachineState from CPU context. This is what I'm working on to avoid for the next version. > 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. Though it's motivated by TDX series, the goal is not TDX specific. The goal is to track features in env->features[] instead of manually generating a one-off value in cpu_x86_cpuid(). > -Zhao >
On Thu, Dec 05, 2024 at 04:05:22PM +0800, Xiaoyao Li wrote: > Date: Thu, 5 Dec 2024 16:05:22 +0800 > From: Xiaoyao Li <xiaoyao.li@intel.com> > Subject: Re: [PATCH v1 0/4] Initialize nr_cores and nr_threads early and > related clearup > > On 12/5/2024 3:30 PM, Zhao Liu wrote: > > 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`. > > yeah, it works. The goal is to maintain HT in env->features[]. > > The problem is, as Igor objects, accessing MachineState from CPU context. > This is what I'm working on to avoid for the next version. :( I also noticed that patch. Adding #ifndef CONFIG_USER_ONLY is not optimal there, so that approach is not general enough. But your TDX case is different, TDX hook has been already under `current_machine` context. So you can directly access any topo info without CONFIG_USER_ONLY. > > 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. > > Though it's motivated by TDX series, the goal is not TDX specific. The goal > is to track features in env->features[] instead of manually generating a > one-off value in cpu_x86_cpuid(). I agree, the principle of designing code should be like this. HT already has some issues, and adding this check in x86_cpu_expand_features() is also a one-off approach with very much effort. Checking HT in TDX is a less costly and less impactful one-off solution. Even, why not ignore HT in the TDX check? Isn't placing the TDX feature check before build_cpuid() implicitly assuming that any subsequent updates to CPUID by QEMU are valid? Based on this, why can't TDX trust that QEMU will set HT correctly? (However, this assumes that HT cannot be arbitrarily set by the user.) I'm not sure how the next version will be, but it would definitely be better if it helps with generalization. Based on the current approach, affecting all architectures, it would be better to directly obtain the topology information from current_machine in TDX. -Zhao
On 12/5/2024 4:48 PM, Zhao Liu wrote: > On Thu, Dec 05, 2024 at 04:05:22PM +0800, Xiaoyao Li wrote: >> Date: Thu, 5 Dec 2024 16:05:22 +0800 >> From: Xiaoyao Li <xiaoyao.li@intel.com> >> Subject: Re: [PATCH v1 0/4] Initialize nr_cores and nr_threads early and >> related clearup >> >> On 12/5/2024 3:30 PM, Zhao Liu wrote: >>> 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`. >> >> yeah, it works. The goal is to maintain HT in env->features[]. >> >> The problem is, as Igor objects, accessing MachineState from CPU context. >> This is what I'm working on to avoid for the next version. > > :( I also noticed that patch. Adding #ifndef CONFIG_USER_ONLY is not > optimal there, so that approach is not general enough. > > But your TDX case is different, TDX hook has been already under > `current_machine` context. So you can directly access any topo info > without CONFIG_USER_ONLY. > >>> 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. >> >> Though it's motivated by TDX series, the goal is not TDX specific. The goal >> is to track features in env->features[] instead of manually generating a >> one-off value in cpu_x86_cpuid(). > > I agree, the principle of designing code should be like this. HT already > has some issues, and adding this check in x86_cpu_expand_features() is > also a one-off approach with very much effort. Checking HT in TDX is a > less costly and less impactful one-off solution. Please disconnect it from TDX. Even without TDX, it's reasonable enough to make the change to track HT in env->features[]. > Even, why not ignore HT in the TDX check? Isn't placing the TDX feature > check before build_cpuid() implicitly assuming that any subsequent > updates to CPUID by QEMU are valid? Why choose to ignore HT in the TDX check? HT isn't special. The problem is just HT is not tracked in env->features[], which is a incorrect design. It assumes the env->features[] is finalized. > Based on this, why can't TDX trust that QEMU will set HT correctly? > (However, this assumes that HT cannot be arbitrarily set by the user.) It's not TDX can't trust QEMU. It's all QEMU's business that QEMU to ensure what it is going to set for TD guest is consistent with what TD guest sees. You are suggesting that when QEMU checks the features, it makes HT a special case that HT's value is finalized later than the check so please ignore HT. What I want to achieve is to get rid of the special case, because HT isn't special. It can be tracked in env->features[] and finalized earlier. > I'm not sure how the next version will be, but it would definitely be > better if it helps with generalization. The goal of this series is exactly generalization to make HT not special. > Based on the current approach, affecting all architectures, it would be > better to directly obtain the topology information from current_machine > in TDX. Imagine why Paolo suggested to post it separately? IIUC, because it's not TDX specific thing. > -Zhao > >
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()? -- Cheers, David / dhildenb
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.
On 11/21/24 17:24, Xiaoyao Li wrote: >> 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. It does look better than the alternative of duplicating code. On the other hand qemu_init_vcpu is already duplicated and I'm not sure I like relying on qdev_get_machine() inside the instance_init function... Paolo
On 11/22/2024 2:52 AM, Paolo Bonzini wrote: > On 11/21/24 17:24, Xiaoyao Li wrote: >>> 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. > > It does look better than the alternative of duplicating code. > > On the other hand qemu_init_vcpu is already duplicated and I'm not sure > I like relying on qdev_get_machine() inside the instance_init function... I had the same concern. But it seems all the ARCHes should create MACHINE before VCPUs. So it seems OK to qdev_get_machine() inside the instance_init function. But I'm not sure if there is any case to create VCPU standalone. I think we can check if qdev_get_machine() gets a valid result. If not, fall back to assign nr_cores and nr_threads to 1. Anyway, please let me know your preference, this series or a v2 to implement it inside cpu_common_initfn(). > Paolo >
On 22.11.24 03:40, Xiaoyao Li wrote: > On 11/22/2024 2:52 AM, Paolo Bonzini wrote: >> On 11/21/24 17:24, Xiaoyao Li wrote: >>>> 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. >> >> It does look better than the alternative of duplicating code. >> >> On the other hand qemu_init_vcpu is already duplicated and I'm not sure >> I like relying on qdev_get_machine() inside the instance_init function... > Good point. > I had the same concern. > > But it seems all the ARCHes should create MACHINE before VCPUs. So it > seems OK to qdev_get_machine() inside the instance_init function. But > I'm not sure if there is any case to create VCPU standalone. There are, for example on s390x in create_cpu_model_list(). I recall there are ways to start QEMU without any machine and trigger that code. (or maybe this was just for the test environment with a special test machine ...) > > I think we can check if qdev_get_machine() gets a valid result. If not, > fall back to assign nr_cores and nr_threads to 1. That sounds reasonable to me. -- Cheers, David / dhildenb
Il ven 22 nov 2024, 10:44 David Hildenbrand <david@redhat.com> ha scritto: > > I think we can check if qdev_get_machine() gets a valid result. If not, > > fall back to assign nr_cores and nr_threads to 1. > > That sounds reasonable to me. > Another possibility is to add a cpu_realize() function that sets two properties and then calls qdev_realize(). It touches all architectures but not in the sense of adding new code, just changing it. And it is more code to write though, so if Xiaoyao prefers that I apply v1 I am okay with that. Paolo > Cheers, > > David / dhildenb > >
On 21/11/24 17:24, Xiaoyao Li wrote: > 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. This seems a x86 issue, it also bugs me: https://lore.kernel.org/qemu-devel/20231128171239.69b6d7b1@imammedo.users.ipa.redhat.com/ IMO we need to make vCPU creation steps more explicit.
© 2016 - 2026 Red Hat, Inc.