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.zh...@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")
