[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] bfef62: target/i386: Use host_vendor_fms() in
From: |
GitHub |
Subject: |
[Qemu-commits] [qemu/qemu] bfef62: target/i386: Use host_vendor_fms() in max_x86_cpu_... |
Date: |
Thu, 27 Jul 2017 02:48:25 -0700 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: bfef624895673866b4beb1757725a565c7048c1f
https://github.com/qemu/qemu/commit/bfef624895673866b4beb1757725a565c7048c1f
Author: Eduardo Habkost <address@hidden>
Date: 2017-07-26 (Wed, 26 Jul 2017)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
target/i386: Use host_vendor_fms() in max_x86_cpu_initfn()
The existing code duplicated the logic in host_vendor_fms(), so
reuse the helper function instead.
Signed-off-by: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
Commit: 7d8050b5142c5b9132be25835a3d7f261f1411a6
https://github.com/qemu/qemu/commit/7d8050b5142c5b9132be25835a3d7f261f1411a6
Author: Eduardo Habkost <address@hidden>
Date: 2017-07-26 (Wed, 26 Jul 2017)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
target/i386: Define CPUID_MODEL_ID_SZ macro
Document cpu_x86_fill_model_id() and define CPUID_MODEL_ID_SZ to
help callers use the right buffer size.
Signed-off-by: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
Commit: bd1820227ecc0c77cc2aeba7c7c25b2d0a72ff3c
https://github.com/qemu/qemu/commit/bd1820227ecc0c77cc2aeba7c7c25b2d0a72ff3c
Author: Eduardo Habkost <address@hidden>
Date: 2017-07-26 (Wed, 26 Jul 2017)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
target/i386: Don't use x86_cpu_load_def() on "max" CPU model
When commit 0bacd8b3046f ('i386: Don't set CPUClass::cpu_def on
"max" model') removed the CPUClass::cpu_def field, we kept using
the x86_cpu_load_def() helper directly in max_x86_cpu_initfn(),
emulating the previous behavior when CPUClass::cpu_def was set.
However, x86_cpu_load_def() is intended to help initialization of
CPU models from the builtin_x86_defs table, and does lots of
other steps that are not necessary for "max".
One of the things x86_cpu_load_def() do is to set the properties
listed at tcg_default_props/kvm_default_props. We must not do
that on the "max" CPU model, otherwise under KVM we will
incorrectly report all KVM features as always available, and the
"svm" feature as always unavailable. The latter caused the bug
reported at:
https://bugzilla.redhat.com/show_bug.cgi?id=1467599
("Unable to start domain: the CPU is incompatible with host CPU:
Host CPU does not provide required features: svm")
Replace x86_cpu_load_def() with simple object_property_set*()
calls. In addition to fixing the above bug, this makes the KVM
branch in max_x86_cpu_initfn() very similar to the existing TCG
branch.
For reference, the full list of steps performed by
x86_cpu_load_def() is:
* Setting min-level and min-xlevel. Already done by
max_x86_cpu_initfn().
* Setting family/model/stepping/model-id. Done by the code added
to max_x86_cpu_initfn() in this patch.
* Copying def->features. Wrong because "-cpu max" features need to
be calculated at realize time. This was not a problem in the
current code because host_cpudef.features was all zeroes.
* x86_cpu_apply_props() calls. This causes the bug above, and
shouldn't be done.
* Setting CPUID_EXT_HYPERVISOR. Not needed because it is already
reported by x86_cpu_get_supported_feature_word(), and because
"-cpu max" features need to be calculated at realize time.
* Setting CPU vendor to host CPU vendor if on KVM mode.
Redundant, because max_x86_cpu_initfn() already sets it to the
host CPU vendor.
Signed-off-by: Eduardo Habkost <address@hidden>
Message-Id: <address@hidden>
Reviewed-by: Igor Mammedov <address@hidden>
Signed-off-by: Eduardo Habkost <address@hidden>
Commit: 2dca6d9e7eb4fb25f1e41024ca20515b38bc8635
https://github.com/qemu/qemu/commit/2dca6d9e7eb4fb25f1e41024ca20515b38bc8635
Author: Peter Maydell <address@hidden>
Date: 2017-07-27 (Thu, 27 Jul 2017)
Changed paths:
M target/i386/cpu.c
Log Message:
-----------
Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' into
staging
x86 bug fix for -rc1
Fix for a bug in "-cpu max" that breaks libvirt usage of
query-cpu-model-expansion.
# gpg: Signature made Wed 26 Jul 2017 19:35:28 BST
# gpg: using RSA key 0x2807936F984DC5A6
# gpg: Good signature from "Eduardo Habkost <address@hidden>"
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6
* remotes/ehabkost/tags/x86-pull-request:
target/i386: Don't use x86_cpu_load_def() on "max" CPU model
target/i386: Define CPUID_MODEL_ID_SZ macro
target/i386: Use host_vendor_fms() in max_x86_cpu_initfn()
Signed-off-by: Peter Maydell <address@hidden>
Compare: https://github.com/qemu/qemu/compare/522fd24ca030...2dca6d9e7eb4
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] bfef62: target/i386: Use host_vendor_fms() in max_x86_cpu_...,
GitHub <=