On Fri, 2020-11-20 at 20:38 +0100, Jiri Denemark wrote:
Doing so would normally break migration to older libvirt, but most
of
the patches in this series prepare an infrastructure for removing
features from existing CPU models while maintaining backward
compatibility during migration.
See patch 7 for more details.
https://bugzilla.redhat.com/show_bug.cgi?id=1798004
Jiri Denemark (8):
conf: Rename virCPUDefUpdateFeatureInternal
conf: Use enum in virCPUDefAddFeatureInternal
conf: Add virCPUDefAddFeatureIfMissing
cpu: Run arch specific code for virCPUUpdate for all custom CPUs
cpu_x86: Change the flow in virCPUx86Update
cpu_x86: Add support for marking features as removed from a CPU
model
cpu_x86: Make sure removed features are always mentioned in CPU def
cpu_map: Drop 'monitor' from modern x86 CPU models
src/conf/cpu_conf.c | 50 +++++--
src/conf/cpu_conf.h | 5 +
src/cpu/cpu.c | 52 +++----
src/cpu/cpu.h | 3 +-
src/cpu/cpu_arm.c | 5 +-
src/cpu/cpu_ppc64.c | 3 +-
src/cpu/cpu_s390.c | 6 +-
src/cpu/cpu_x86.c | 127 ++++++++++++++
----
src/cpu_map/x86_Dhyana.xml | 2 +-
src/cpu_map/x86_EPYC-IBPB.xml | 2 +-
src/cpu_map/x86_EPYC.xml | 2 +-
src/cpu_map/x86_Opteron_G3.xml | 2 +-
src/libvirt_private.syms | 1 +
.../x86_64-cpuid-EPYC-7601-32-Core-guest.xml | 1 +
.../x86_64-cpuid-EPYC-7601-32-Core-host.xml | 1 +
..._64-cpuid-EPYC-7601-32-Core-ibpb-guest.xml | 1 +
...6_64-cpuid-EPYC-7601-32-Core-ibpb-host.xml | 1 +
...6_64-cpuid-EPYC-7601-32-Core-ibpb-json.xml | 2 +-
.../x86_64-cpuid-EPYC-7601-32-Core-json.xml | 2 +-
..._64-cpuid-Hygon-C86-7185-32-core-guest.xml | 1 +
...6_64-cpuid-Hygon-C86-7185-32-core-host.xml | 1 +
...6_64-cpuid-Hygon-C86-7185-32-core-json.xml | 2 +-
.../x86_64-cpuid-Opteron-1352-guest.xml | 1 +
.../x86_64-cpuid-Opteron-1352-host.xml | 1 +
.../x86_64-cpuid-Opteron-2350-guest.xml | 1 +
.../x86_64-cpuid-Opteron-2350-host.xml | 1 +
.../x86_64-cpuid-Opteron-2350-json.xml | 2 +-
.../x86_64-cpuid-Phenom-B95-guest.xml | 1 +
.../x86_64-cpuid-Phenom-B95-json.xml | 2 +-
...4-cpuid-Ryzen-7-1800X-Eight-Core-guest.xml | 1 +
...64-cpuid-Ryzen-7-1800X-Eight-Core-host.xml | 1 +
...64-cpuid-Ryzen-7-1800X-Eight-Core-json.xml | 2 +-
.../domaincapsdata/qemu_2.11.0-tcg.x86_64.xml | 1 +
.../domaincapsdata/qemu_2.12.0-tcg.x86_64.xml | 1 +
.../domaincapsdata/qemu_3.0.0-tcg.x86_64.xml | 1 +
.../domaincapsdata/qemu_3.1.0-tcg.x86_64.xml | 1 +
.../domaincapsdata/qemu_4.0.0-tcg.x86_64.xml | 1 +
.../domaincapsdata/qemu_4.1.0-tcg.x86_64.xml | 1 +
.../domaincapsdata/qemu_4.2.0-tcg.x86_64.xml | 1 +
.../domaincapsdata/qemu_5.0.0-tcg.x86_64.xml | 1 +
.../domaincapsdata/qemu_5.1.0-tcg.x86_64.xml | 1 +
.../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml | 1 +
.../cpu-host-model-cmt.x86_64-4.0.0.args | 6 +-
43 files changed, 223 insertions(+), 78 deletions(-)
lgtm.
Do we want to have a schema for the cpu definitions in src/cpu_map/
somewhen, maybe as a "bite sized task"? I do understand it is kind of
superfluous, but if it *can* be tested automatically...
Reviewed-by: Tim Wiederhake <twiederh(a)redhat.com>
Cheers,
Tim