]> git.proxmox.com Git - mirror_qemu.git/commit
pc: Use "min-[x]level" on compat_props
authorEduardo Habkost <ehabkost@redhat.com>
Mon, 5 Jun 2017 15:19:27 +0000 (12:19 -0300)
committerMichael Roth <mdroth@linux.vnet.ibm.com>
Thu, 3 Aug 2017 21:01:29 +0000 (16:01 -0500)
commit2401d8a490e728f2a63ac7a0c875f969cd298c46
treee1db7347f44ce2f36d2f6e7f7496baf76f759a14
parent1775fe6148ae11a4e8ad6f6c2813a41e70e12f76
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>
(cherry picked from commit 1f43571604da85c62f25f3ba6d275b1b5ea76ca2)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
include/hw/i386/pc.h
tests/test-x86-cpuid-compat.c