aboutsummaryrefslogtreecommitdiff
path: root/numa.c
diff options
context:
space:
mode:
authorEduardo Habkost <ehabkost@redhat.com>2017-06-05 12:19:27 -0300
committerEduardo Habkost <ehabkost@redhat.com>2017-06-05 14:59:08 -0300
commit1f43571604da85c62f25f3ba6d275b1b5ea76ca2 (patch)
treefb580aa4c2a840f090b6be9857e1b60d401bda13 /numa.c
parentcb8b8ef4578dc17c350fd4b27700a9f178e2dad0 (diff)
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 'numa.c')
0 files changed, 0 insertions, 0 deletions