diff options
author | Eduardo Habkost <ehabkost@redhat.com> | 2017-06-05 12:19:27 -0300 |
---|---|---|
committer | Eduardo Habkost <ehabkost@redhat.com> | 2017-06-05 14:59:08 -0300 |
commit | 1f43571604da85c62f25f3ba6d275b1b5ea76ca2 (patch) | |
tree | fb580aa4c2a840f090b6be9857e1b60d401bda13 /hw/arm | |
parent | cb8b8ef4578dc17c350fd4b27700a9f178e2dad0 (diff) | |
download | qemu-1f43571604da85c62f25f3ba6d275b1b5ea76ca2.zip qemu-1f43571604da85c62f25f3ba6d275b1b5ea76ca2.tar.gz qemu-1f43571604da85c62f25f3ba6d275b1b5ea76ca2.tar.bz2 |
pc: Use "min-[x]level" on compat_props
Since the automatic cpuid-level code was introduced in commit
c39c0edf9bb3b968ba95484465a50c7b19f4aa3a ("target-i386: Automatically
set level/xlevel/xlevel2 when needed"), the CPU model tables just define
the default CPUID level code (set using "min-level"). Setting
"[x]level" forces CPUID level to a specific value and disable the
automatic-level logic.
But the PC compat code was not updated and the existing "[x]level"
compat properties broke compatibility for people using features that
triggered the auto-level code. To keep previous behavior, we should set
"min-[x]level" instead of "[x]level" on compat_props.
This was not a problem for most cases, because old machine-types don't
have full-cpuid-auto-level enabled. The only common use case it broke
was the CPUID[7] auto-level code, that was already enabled since the
first CPUID[7] feature was introduced (in QEMU 1.4.0).
This causes the regression reported at:
https://bugzilla.redhat.com/show_bug.cgi?id=1454641
Change the PC compat code to use "min-[x]level" instead of "[x]level" on
compat_props, and add new test cases to ensure we don't break this
again.
Reported-by: "Guo, Zhiyi" <zhguo@redhat.com>
Fixes: c39c0edf9bb ("target-i386: Automatically set level/xlevel/xlevel2 when needed")
Cc: qemu-stable@nongnu.org
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Diffstat (limited to 'hw/arm')
0 files changed, 0 insertions, 0 deletions