Re: [Regression] Re: [PULL 35/35] qom: reverse order of instance_post_init calls

[Zhao Liu <zhao1.liu@intel.com>]

On Mon, Jun 23, 2025 at 09:56:14AM -0700, Dongli Zhang wrote:
> Date: Mon, 23 Jun 2025 09:56:14 -0700
> From: Dongli Zhang <dongli.zhang@oracle.com>
> Subject: [Regression] Re: [PULL 35/35] qom: reverse order of
>  instance_post_init calls
> 
> This commit may broken the "vendor=" configuration.
> 
> For instance, the hypervisor CPU vendor is AMD.
> 
> I am going to use "-cpu Skylake-Server,vendor=GenuineIntel".
> 
> 
> Because of the commit, the vendor is still AMD.
> 
> [root@vm ~]# cpuid -1 -l 0x0
> CPU:
>    vendor_id = "AuthenticAMD"
> 
> 
> If I revert this patch, the vendor because the expected Intel.
> 
> [root@vm ~]# cpuid -1 -l 0x0
> CPU:
>    vendor_id = "GenuineIntel"
> 
> 
> Thank you very much!

Thank you Dongli!

(+Like)

While testing my cache model series, I also noticed the similar behavior
for KVM. Additionally, Like Xu reported to me that this commit caused
a failure in a KVM unit test case. Your report helped me connect these
two issues I met (though due to my environment issues, I haven't
confirmed yet).

The "vendor" property from cli is registered as the global property in
x86_cpu_parse_featurestr(), and is applied to x86 CPUs in
device_post_init().

With this commit, now KVM will override the "vendor" in
host_cpu_instance_init() (called in x86_cpu_post_initfn()) after
device_post_init(), regardless the previous global "vendor" property.

Back to this commit, I think current order of post_init  makes sense.
Instead, the place of host_cpu_instance_init() doesn't seem quite
right. So, I think this commit might have exposed some drawbacks in the
previous x86 CPU initialization order:

f5cc5a5c1686 ("i386: split cpu accelerators from cpu.c, using AccelCPUClass")
5b8978d80426 ("i386: do not call cpudef-only models functions for max, host, base")