On 10/04/2017 10:58 AM, Jiri Denemark wrote:
This CPU was incorrectly detected as SandyBridge before because the
number of additional <feature> elements was the same for both
SandyBridge and Westmere CPU models, but SandyBridge is newer (the CPU
signature does not help here because it doesn't match any signature
defined in cpu_map.xml). But since QEMU's version of SandyBridge CPU
model contains xsaveopt which needs to be disabled, Westmere becomes the
best CPU model when translating CPUID data to virCPUDef. Unfortunately,
this doesn't help with translating the data we got from QEMU and the CPU
model is still computed as SandyBridge in this case.
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
tests/cputest.c | 2 +-
.../x86_64-cpuid-Xeon-E7-4830-guest.xml | 8 +-
.../cputestdata/x86_64-cpuid-Xeon-E7-4830-json.xml | 1 +
tests/cputestdata/x86_64-cpuid-Xeon-E7-4830.json | 422 +++++++++++++++++++++
4 files changed, 428 insertions(+), 5 deletions(-)
Similar "mpx" duplication, but otherwise seemingly fine.
Reviewed-by: John Ferlan <jferlan(a)redhat.com>
John