[PATCH] qemu: Validate QoS values in qemuDomainSetInterfaceParameters()
by Michal Privoznik
This is similar to one of my previous commits (v10.7.0-rc1~22)
which introduce a check that <bandwidth/> values fit into certain
limits. My original commit validated values when parsing
<bandwidth/> XML, but completely missed the case when values are
set over virDomainSetInterfaceParameters() API.
Solution is simple - just perform validation after bandwidth
structure is reconstructed from arguments passed to the API.
Resolves: https://issues.redhat.com/browse/RHEL-65372
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_driver.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index d1b32de56a..09f7edda7d 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -9883,6 +9883,9 @@ qemuDomainSetInterfaceParameters(virDomainPtr dom,
if (!bandwidth->out->average)
VIR_FREE(bandwidth->out);
+ if (!virNetDevBandwidthValidate(bandwidth))
+ goto endjob;
+
if (net) {
newBandwidth = g_new0(virNetDevBandwidth, 1);
--
2.45.2
4 months, 1 week
[PATCH] NEWS: Document support for versioned CPU models
by Jiri Denemark
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
NEWS.rst | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/NEWS.rst b/NEWS.rst
index 88ac38834a..557c5b18d3 100644
--- a/NEWS.rst
+++ b/NEWS.rst
@@ -33,6 +33,11 @@ v10.10.0 (unreleased)
Limitation: The s390x BIOS will try to IPL up to 8 total devices, any
number of which may be disks or network devices.
+ * qemu: Add support for versioned CPU models
+
+ Updates to QEMU CPU models with -vN suffix can now be used in libvirt just
+ like any other CPU model.
+
* **Improvements**
* **Bug fixes**
--
2.47.0
4 months, 1 week
[PATCH] cpu: Check blockers in virCPUCompareUnusable only if they exist
by Jiri Denemark
virCPUCompareUnusable can be called with blockers == NULL in case the
CPU model itself is usable (i.e., QEMU reports an empty list of
blockers), but the CPU definition contains some additional features
which have to be checked.
Fixes: v10.8.0-129-g5f8abbb7d0
Reported-by: Han Han <hhan(a)redhat.com>
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
src/cpu/cpu.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/cpu/cpu.c b/src/cpu/cpu.c
index 2b0d641e78..58fba3781c 100644
--- a/src/cpu/cpu.c
+++ b/src/cpu/cpu.c
@@ -201,11 +201,13 @@ virCPUCompareUnusable(virArch arch,
char **blocker;
size_t i;
- for (blocker = blockers; *blocker; blocker++) {
- if (!(feat = virCPUDefFindFeature(cpu, *blocker)) ||
- feat->policy != VIR_CPU_FEATURE_DISABLE) {
- virBufferAddStr(&features, *blocker);
- virBufferAddLit(&features, ", ");
+ if (blockers) {
+ for (blocker = blockers; *blocker; blocker++) {
+ if (!(feat = virCPUDefFindFeature(cpu, *blocker)) ||
+ feat->policy != VIR_CPU_FEATURE_DISABLE) {
+ virBufferAddStr(&features, *blocker);
+ virBufferAddLit(&features, ", ");
+ }
}
}
--
2.47.0
4 months, 1 week
[PATCH v2 00/36] Add support for versioned CPU models
by Jiri Denemark
Each CPU model with -v* suffix is defined as a standalone model copying
all attributes of the previous version although CPU model versions with
an alias are handled differently. The full definition is used for the
alias and the versioned model is created as an identical copy of the
alias.
To avoid breaking migration compatibility of host-model CPUs all
versioned models are marked with <decode guest='off'/> so that they are
ignored when selecting candidates for host-model. It's not ideal but not
doing so would break almost all host-model CPUs as the new versioned CPU
models have all vmx-* features included since their introduction while
existing CPU models were updated later. This meas existing models would
be accompanied with a long list of vmx-* features to properly describe a
host CPU while the newly added CPU models would have those features
enabled implicitly and their list of features would be significantly
shorter. Thus the new models would always be better candidates for
host-model than the existing models.
Version 2:
- removed patches
- cpu_x86: Copy added and removed features from ancestor
- qemu: Canonicalize CPU models
- new patches
- cpu_x86: Annotate virCPUx86Model fields
- cpu_x86: Promote added/removed from ancestor
- cpu_x86: Record relations between CPU models
- cpu: Introduce virCPUGetCanonicalModel
- domain_capabilities: Report canonical names of CPU models
- cpu_map: Add Denverton CPU model
- cpu_map: Add KnightsMill CPU model
- make -v? variants linked to their corresponding non-versioned models
(such as -noTSX, -IBRS, etc.)
- all -v? variants are marked with <decode host='on' guest='off'/>
- do not add absolute path to CPU model XMLs to index.xml
- use <group name='...'> for all groups rather than a strange mix of
<group name='...'> and <group vendor='...'>
Jiri Denemark (36):
cpu_x86: Annotate virCPUx86Model fields
cpu_x86: Promote added/removed from ancestor
sync_qemu_features_i386: Add some removed features back
sync_qemu_models_i386: Use f-strings
sync_qemu_models_i386: Do not overwrite existing models
sync_qemu_models_i386: Do not require full path to QEMU's cpu.c
sync_qemu_models_i386: Add support for versioned CPU models
sync_qemu_models_i386: Store extra info in a separate file
sync_qemu_models_i386: Switch to lxml
cpu_map: Properly group models in index.xml
sync_qemu_models_i386: Update index.xml
sync_qemu_models_i386: Copy signatures from base model
cpu_x86: Record relations between CPU models
cpu: Introduce virCPUGetCanonicalModel
domain_capabilities: Report canonical names of CPU models
cpu_map: Add versions of SierraForest CPU model
cpu_map: Add versions of GraniteRapids CPU model
cpu_map: Add versions of SapphireRapids CPU model
cpu_map: Add versions of Snowridge CPU model
cpu_map: Add versions of Cooperlake CPU model
cpu_map: Add versions of Icelake-Server CPU model
cpu_map: Add versions of Cascadelake-Server CPU model
cpu_map: Add versions of Skylake-Server CPU model
cpu_map: Add versions of Skylake-Client CPU model
cpu_map: Add versions of Broadwell CPU model
cpu_map: Add versions of Haswell CPU model
cpu_map: Add versions of IvyBridge CPU model
cpu_map: Add versions of SandyBridge CPU model
cpu_map: Add versions of Westmere CPU model
cpu_map: Add versions of Nehalem CPU model
cpu_map: Add versions of EPYC-Milan CPU model
cpu_map: Add versions of EPYC-Rome CPU model
cpu_map: Add versions of EPYC CPU model
cpu_map: Add versions of Dhyana CPU model
cpu_map: Add Denverton CPU model
cpu_map: Add KnightsMill CPU model
docs/formatdomaincaps.rst | 8 +-
src/conf/domain_capabilities.c | 11 +-
src/conf/domain_capabilities.h | 4 +-
src/cpu/cpu.c | 25 +
src/cpu/cpu.h | 8 +
src/cpu/cpu_map.c | 2 +-
src/cpu/cpu_x86.c | 88 +-
src/cpu_map/index.xml | 291 ++--
src/cpu_map/meson.build | 60 +
src/cpu_map/sync_qemu_features_i386.py | 3 +
src/cpu_map/sync_qemu_models_i386.py | 184 +-
src/cpu_map/x86_Broadwell-v1.xml | 6 +
src/cpu_map/x86_Broadwell-v2.xml | 6 +
src/cpu_map/x86_Broadwell-v3.xml | 6 +
src/cpu_map/x86_Broadwell-v4.xml | 6 +
src/cpu_map/x86_Cascadelake-Server-v1.xml | 6 +
src/cpu_map/x86_Cascadelake-Server-v2.xml | 157 ++
src/cpu_map/x86_Cascadelake-Server-v3.xml | 6 +
src/cpu_map/x86_Cascadelake-Server-v4.xml | 156 ++
src/cpu_map/x86_Cascadelake-Server-v5.xml | 158 ++
src/cpu_map/x86_Cooperlake-v1.xml | 6 +
src/cpu_map/x86_Cooperlake-v2.xml | 164 ++
src/cpu_map/x86_Denverton-v1.xml | 6 +
src/cpu_map/x86_Denverton-v2.xml | 137 ++
src/cpu_map/x86_Denverton-v3.xml | 139 ++
src/cpu_map/x86_Denverton.xml | 138 ++
src/cpu_map/x86_Dhyana-v1.xml | 6 +
src/cpu_map/x86_Dhyana-v2.xml | 73 +
src/cpu_map/x86_EPYC-Milan-v1.xml | 6 +
src/cpu_map/x86_EPYC-Milan-v2.xml | 99 ++
src/cpu_map/x86_EPYC-Rome-v1.xml | 6 +
src/cpu_map/x86_EPYC-Rome-v2.xml | 86 +
src/cpu_map/x86_EPYC-Rome-v3.xml | 86 +
src/cpu_map/x86_EPYC-Rome-v4.xml | 85 +
src/cpu_map/x86_EPYC-v1.xml | 6 +
src/cpu_map/x86_EPYC-v2.xml | 6 +
src/cpu_map/x86_EPYC-v3.xml | 79 +
src/cpu_map/x86_EPYC-v4.xml | 79 +
src/cpu_map/x86_GraniteRapids-v1.xml | 6 +
src/cpu_map/x86_Haswell-v1.xml | 6 +
src/cpu_map/x86_Haswell-v2.xml | 6 +
src/cpu_map/x86_Haswell-v3.xml | 6 +
src/cpu_map/x86_Haswell-v4.xml | 6 +
src/cpu_map/x86_Icelake-Server-v1.xml | 6 +
src/cpu_map/x86_Icelake-Server-v2.xml | 6 +
src/cpu_map/x86_Icelake-Server-v3.xml | 165 ++
src/cpu_map/x86_Icelake-Server-v4.xml | 172 ++
src/cpu_map/x86_Icelake-Server-v5.xml | 174 ++
src/cpu_map/x86_Icelake-Server-v6.xml | 175 ++
src/cpu_map/x86_Icelake-Server-v7.xml | 177 ++
src/cpu_map/x86_IvyBridge-v1.xml | 6 +
src/cpu_map/x86_IvyBridge-v2.xml | 6 +
src/cpu_map/x86_KnightsMill.xml | 71 +
src/cpu_map/x86_Nehalem-v1.xml | 6 +
src/cpu_map/x86_Nehalem-v2.xml | 6 +
src/cpu_map/x86_SandyBridge-v1.xml | 6 +
src/cpu_map/x86_SandyBridge-v2.xml | 6 +
src/cpu_map/x86_SapphireRapids-v1.xml | 6 +
src/cpu_map/x86_SapphireRapids-v2.xml | 193 +++
src/cpu_map/x86_SapphireRapids-v3.xml | 198 +++
src/cpu_map/x86_SierraForest-v1.xml | 6 +
src/cpu_map/x86_Skylake-Client-v1.xml | 6 +
src/cpu_map/x86_Skylake-Client-v2.xml | 6 +
src/cpu_map/x86_Skylake-Client-v3.xml | 6 +
src/cpu_map/x86_Skylake-Client-v4.xml | 141 ++
src/cpu_map/x86_Skylake-Server-v1.xml | 6 +
src/cpu_map/x86_Skylake-Server-v2.xml | 6 +
src/cpu_map/x86_Skylake-Server-v3.xml | 6 +
src/cpu_map/x86_Skylake-Server-v4.xml | 148 ++
src/cpu_map/x86_Skylake-Server-v5.xml | 150 ++
src/cpu_map/x86_Snowridge-v1.xml | 6 +
src/cpu_map/x86_Snowridge-v2.xml | 143 ++
src/cpu_map/x86_Snowridge-v3.xml | 145 ++
src/cpu_map/x86_Snowridge-v4.xml | 143 ++
src/cpu_map/x86_Westmere-v1.xml | 6 +
src/cpu_map/x86_Westmere-v2.xml | 6 +
src/libvirt_private.syms | 1 +
src/qemu/qemu_capabilities.c | 10 +-
tests/cputest.c | 5 +-
.../x86_64-cpuid-Atom-P5362-host.xml | 2 +-
.../x86_64-cpuid-Cooperlake-host.xml | 2 +-
.../x86_64-cpuid-Core-i5-2500-host.xml | 2 +-
.../x86_64-cpuid-Core-i5-2540M-host.xml | 2 +-
.../x86_64-cpuid-Core-i5-4670T-host.xml | 2 +-
.../x86_64-cpuid-Core-i5-650-host.xml | 2 +-
.../x86_64-cpuid-Core-i5-6600-host.xml | 2 +-
.../x86_64-cpuid-Core-i7-2600-host.xml | 2 +-
...86_64-cpuid-Core-i7-2600-xsaveopt-host.xml | 2 +-
.../x86_64-cpuid-Core-i7-3520M-host.xml | 2 +-
.../x86_64-cpuid-Core-i7-3740QM-host.xml | 2 +-
.../x86_64-cpuid-Core-i7-3770-host.xml | 2 +-
.../x86_64-cpuid-Core-i7-4510U-host.xml | 2 +-
.../x86_64-cpuid-Core-i7-4600U-host.xml | 2 +-
.../x86_64-cpuid-Core-i7-5600U-arat-host.xml | 2 +-
.../x86_64-cpuid-Core-i7-5600U-host.xml | 2 +-
.../x86_64-cpuid-Core-i7-5600U-ibrs-host.xml | 2 +-
.../x86_64-cpuid-Core-i7-7600U-host.xml | 2 +-
.../x86_64-cpuid-Core-i7-7700-host.xml | 2 +-
.../x86_64-cpuid-Core-i7-8550U-host.xml | 2 +-
.../x86_64-cpuid-Core-i7-8700-host.xml | 2 +-
.../x86_64-cpuid-EPYC-7502-32-Core-host.xml | 5 +-
.../x86_64-cpuid-EPYC-7601-32-Core-host.xml | 2 +-
...6_64-cpuid-EPYC-7601-32-Core-ibpb-host.xml | 8 +-
...6_64-cpuid-Hygon-C86-7185-32-core-host.xml | 5 +-
.../x86_64-cpuid-Ice-Lake-Server-host.xml | 2 +-
...64-cpuid-Ryzen-7-1800X-Eight-Core-host.xml | 2 +-
...86_64-cpuid-Ryzen-9-3900X-12-Core-host.xml | 2 +-
.../x86_64-cpuid-Xeon-E3-1225-v5-host.xml | 2 +-
.../x86_64-cpuid-Xeon-E3-1245-v5-host.xml | 2 +-
.../x86_64-cpuid-Xeon-E5-2609-v3-host.xml | 2 +-
.../x86_64-cpuid-Xeon-E5-2623-v4-host.xml | 2 +-
.../x86_64-cpuid-Xeon-E5-2630-v3-host.xml | 2 +-
.../x86_64-cpuid-Xeon-E5-2630-v4-host.xml | 2 +-
.../x86_64-cpuid-Xeon-E5-2650-host.xml | 2 +-
.../x86_64-cpuid-Xeon-E5-2650-v3-host.xml | 2 +-
.../x86_64-cpuid-Xeon-E5-2650-v4-host.xml | 2 +-
.../x86_64-cpuid-Xeon-E7-4820-host.xml | 2 +-
.../x86_64-cpuid-Xeon-E7-4830-host.xml | 2 +-
.../x86_64-cpuid-Xeon-E7-8890-v3-host.xml | 2 +-
.../x86_64-cpuid-Xeon-E7540-host.xml | 2 +-
.../x86_64-cpuid-Xeon-Gold-5115-host.xml | 2 +-
.../x86_64-cpuid-Xeon-Gold-6130-host.xml | 2 +-
.../x86_64-cpuid-Xeon-Gold-6148-host.xml | 2 +-
.../x86_64-cpuid-Xeon-Platinum-8268-host.xml | 2 +-
.../x86_64-cpuid-Xeon-Platinum-9242-host.xml | 2 +-
.../x86_64-cpuid-Xeon-W3520-host.xml | 2 +-
.../domaincapsdata/qemu_5.2.0-q35.x86_64.xml | 462 ++++-
.../domaincapsdata/qemu_5.2.0-tcg.x86_64.xml | 836 +++++++++-
tests/domaincapsdata/qemu_5.2.0.x86_64.xml | 462 ++++-
.../domaincapsdata/qemu_6.0.0-q35.x86_64.xml | 477 +++++-
.../domaincapsdata/qemu_6.0.0-tcg.x86_64.xml | 896 +++++++++-
tests/domaincapsdata/qemu_6.0.0.x86_64.xml | 477 +++++-
.../domaincapsdata/qemu_6.1.0-q35.x86_64.xml | 576 ++++++-
.../domaincapsdata/qemu_6.1.0-tcg.x86_64.xml | 1458 +++++++++++++---
tests/domaincapsdata/qemu_6.1.0.x86_64.xml | 576 ++++++-
.../domaincapsdata/qemu_6.2.0-q35.x86_64.xml | 583 ++++++-
.../domaincapsdata/qemu_6.2.0-tcg.x86_64.xml | 1461 +++++++++++++---
tests/domaincapsdata/qemu_6.2.0.x86_64.xml | 583 ++++++-
.../domaincapsdata/qemu_7.0.0-q35.x86_64.xml | 609 ++++++-
.../domaincapsdata/qemu_7.0.0-tcg.x86_64.xml | 1485 ++++++++++++++---
tests/domaincapsdata/qemu_7.0.0.x86_64.xml | 609 ++++++-
.../domaincapsdata/qemu_7.1.0-q35.x86_64.xml | 609 ++++++-
.../domaincapsdata/qemu_7.1.0-tcg.x86_64.xml | 1425 +++++++++++++---
tests/domaincapsdata/qemu_7.1.0.x86_64.xml | 609 ++++++-
.../domaincapsdata/qemu_7.2.0-q35.x86_64.xml | 609 ++++++-
.../qemu_7.2.0-tcg.x86_64+hvf.xml | 979 ++++++++++-
.../domaincapsdata/qemu_7.2.0-tcg.x86_64.xml | 979 ++++++++++-
tests/domaincapsdata/qemu_7.2.0.x86_64.xml | 609 ++++++-
.../domaincapsdata/qemu_8.0.0-q35.x86_64.xml | 652 +++++++-
.../domaincapsdata/qemu_8.0.0-tcg.x86_64.xml | 1015 ++++++++++-
tests/domaincapsdata/qemu_8.0.0.x86_64.xml | 652 +++++++-
.../domaincapsdata/qemu_8.1.0-q35.x86_64.xml | 815 ++++++++-
.../domaincapsdata/qemu_8.1.0-tcg.x86_64.xml | 1063 +++++++++++-
tests/domaincapsdata/qemu_8.1.0.x86_64.xml | 815 ++++++++-
.../domaincapsdata/qemu_8.2.0-q35.x86_64.xml | 815 ++++++++-
.../domaincapsdata/qemu_8.2.0-tcg.x86_64.xml | 959 ++++++++++-
tests/domaincapsdata/qemu_8.2.0.x86_64.xml | 815 ++++++++-
.../domaincapsdata/qemu_9.0.0-q35.x86_64.xml | 815 ++++++++-
.../domaincapsdata/qemu_9.0.0-tcg.x86_64.xml | 915 +++++++++-
tests/domaincapsdata/qemu_9.0.0.x86_64.xml | 815 ++++++++-
.../domaincapsdata/qemu_9.1.0-q35.x86_64.xml | 922 +++++++++-
.../domaincapsdata/qemu_9.1.0-tcg.x86_64.xml | 1139 +++++++++++--
tests/domaincapsdata/qemu_9.1.0.x86_64.xml | 922 +++++++++-
.../domaincapsdata/qemu_9.2.0-q35.x86_64.xml | 922 +++++++++-
.../domaincapsdata/qemu_9.2.0-tcg.x86_64.xml | 1139 +++++++++++--
tests/domaincapsdata/qemu_9.2.0.x86_64.xml | 922 +++++++++-
166 files changed, 35711 insertions(+), 2629 deletions(-)
create mode 100644 src/cpu_map/x86_Broadwell-v1.xml
create mode 100644 src/cpu_map/x86_Broadwell-v2.xml
create mode 100644 src/cpu_map/x86_Broadwell-v3.xml
create mode 100644 src/cpu_map/x86_Broadwell-v4.xml
create mode 100644 src/cpu_map/x86_Cascadelake-Server-v1.xml
create mode 100644 src/cpu_map/x86_Cascadelake-Server-v2.xml
create mode 100644 src/cpu_map/x86_Cascadelake-Server-v3.xml
create mode 100644 src/cpu_map/x86_Cascadelake-Server-v4.xml
create mode 100644 src/cpu_map/x86_Cascadelake-Server-v5.xml
create mode 100644 src/cpu_map/x86_Cooperlake-v1.xml
create mode 100644 src/cpu_map/x86_Cooperlake-v2.xml
create mode 100644 src/cpu_map/x86_Denverton-v1.xml
create mode 100644 src/cpu_map/x86_Denverton-v2.xml
create mode 100644 src/cpu_map/x86_Denverton-v3.xml
create mode 100644 src/cpu_map/x86_Denverton.xml
create mode 100644 src/cpu_map/x86_Dhyana-v1.xml
create mode 100644 src/cpu_map/x86_Dhyana-v2.xml
create mode 100644 src/cpu_map/x86_EPYC-Milan-v1.xml
create mode 100644 src/cpu_map/x86_EPYC-Milan-v2.xml
create mode 100644 src/cpu_map/x86_EPYC-Rome-v1.xml
create mode 100644 src/cpu_map/x86_EPYC-Rome-v2.xml
create mode 100644 src/cpu_map/x86_EPYC-Rome-v3.xml
create mode 100644 src/cpu_map/x86_EPYC-Rome-v4.xml
create mode 100644 src/cpu_map/x86_EPYC-v1.xml
create mode 100644 src/cpu_map/x86_EPYC-v2.xml
create mode 100644 src/cpu_map/x86_EPYC-v3.xml
create mode 100644 src/cpu_map/x86_EPYC-v4.xml
create mode 100644 src/cpu_map/x86_GraniteRapids-v1.xml
create mode 100644 src/cpu_map/x86_Haswell-v1.xml
create mode 100644 src/cpu_map/x86_Haswell-v2.xml
create mode 100644 src/cpu_map/x86_Haswell-v3.xml
create mode 100644 src/cpu_map/x86_Haswell-v4.xml
create mode 100644 src/cpu_map/x86_Icelake-Server-v1.xml
create mode 100644 src/cpu_map/x86_Icelake-Server-v2.xml
create mode 100644 src/cpu_map/x86_Icelake-Server-v3.xml
create mode 100644 src/cpu_map/x86_Icelake-Server-v4.xml
create mode 100644 src/cpu_map/x86_Icelake-Server-v5.xml
create mode 100644 src/cpu_map/x86_Icelake-Server-v6.xml
create mode 100644 src/cpu_map/x86_Icelake-Server-v7.xml
create mode 100644 src/cpu_map/x86_IvyBridge-v1.xml
create mode 100644 src/cpu_map/x86_IvyBridge-v2.xml
create mode 100644 src/cpu_map/x86_KnightsMill.xml
create mode 100644 src/cpu_map/x86_Nehalem-v1.xml
create mode 100644 src/cpu_map/x86_Nehalem-v2.xml
create mode 100644 src/cpu_map/x86_SandyBridge-v1.xml
create mode 100644 src/cpu_map/x86_SandyBridge-v2.xml
create mode 100644 src/cpu_map/x86_SapphireRapids-v1.xml
create mode 100644 src/cpu_map/x86_SapphireRapids-v2.xml
create mode 100644 src/cpu_map/x86_SapphireRapids-v3.xml
create mode 100644 src/cpu_map/x86_SierraForest-v1.xml
create mode 100644 src/cpu_map/x86_Skylake-Client-v1.xml
create mode 100644 src/cpu_map/x86_Skylake-Client-v2.xml
create mode 100644 src/cpu_map/x86_Skylake-Client-v3.xml
create mode 100644 src/cpu_map/x86_Skylake-Client-v4.xml
create mode 100644 src/cpu_map/x86_Skylake-Server-v1.xml
create mode 100644 src/cpu_map/x86_Skylake-Server-v2.xml
create mode 100644 src/cpu_map/x86_Skylake-Server-v3.xml
create mode 100644 src/cpu_map/x86_Skylake-Server-v4.xml
create mode 100644 src/cpu_map/x86_Skylake-Server-v5.xml
create mode 100644 src/cpu_map/x86_Snowridge-v1.xml
create mode 100644 src/cpu_map/x86_Snowridge-v2.xml
create mode 100644 src/cpu_map/x86_Snowridge-v3.xml
create mode 100644 src/cpu_map/x86_Snowridge-v4.xml
create mode 100644 src/cpu_map/x86_Westmere-v1.xml
create mode 100644 src/cpu_map/x86_Westmere-v2.xml
--
2.47.0
4 months, 1 week
Re: [PATCH v2 4/5] virsh: add --disable-deprecated-features flag to
domcapabilities
by Boris Fiuczynski
On 11/26/24 16:14, Boris Fiuczynski wrote:
> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com>
>
> On 11/25/24 20:46, Collin Walling wrote:
>> Add a new flag, --disable-deprecated-features, to the domcapabilities
>> command. This will modify the output to show the 'host-model' CPU
>> with features flagged as deprecated paired with the 'disable' policy.
>>
>> virsh domcapabilities --disable-deprecated-features
>>
>> Signed-off-by: Collin Walling <walling(a)linux.ibm.com>
>> ---
>> docs/manpages/virsh.rst | 6 ++++++
>> include/libvirt/libvirt-domain.h | 12 ++++++++++++
>> src/libvirt-domain.c | 2 +-
>> src/qemu/qemu_capabilities.c | 20 ++++++++++++++++++++
>> src/qemu/qemu_capabilities.h | 3 +++
>> src/qemu/qemu_driver.c | 8 +++++++-
>> tools/virsh-host.c | 9 ++++++++-
>> 7 files changed, 57 insertions(+), 3 deletions(-)
>>
>> diff --git a/docs/manpages/virsh.rst b/docs/manpages/virsh.rst
>> index 2e525d3fac..d3b8ff4e1c 100644
>> --- a/docs/manpages/virsh.rst
>> +++ b/docs/manpages/virsh.rst
>> @@ -568,6 +568,7 @@ domcapabilities
>> domcapabilities [virttype] [emulatorbin] [arch] [machine]
>> [--xpath EXPRESSION] [--wrap]
>> + [--disabled-deprecated-features]
>> Print an XML document describing the domain capabilities for the
>> @@ -609,6 +610,11 @@ a standalone document, however, for ease of
>> additional processing,
>> the **--wrap** argument will cause the matching node to be wrapped
>> in a common root node.
>> +The **--disabled-deprecated-features** argument will modify the contents
>> +of host-model CPU XML, updating the features list with any features
>> +flagged as deprecated for the CPU model by the hypervisor. These
>> +features will be paired with the "disable" policy.
>> +
>> pool-capabilities
>> -----------------
>> diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/
>> libvirt-domain.h
>> index d4f1573954..0d7e54a3dc 100644
>> --- a/include/libvirt/libvirt-domain.h
>> +++ b/include/libvirt/libvirt-domain.h
>> @@ -1491,6 +1491,18 @@ int virDomainMigrateGetMaxSpeed(virDomainPtr
>> domain,
>> int virDomainMigrateStartPostCopy(virDomainPtr domain,
>> unsigned int flags);
>> +/**
>> + * virConnectGetDomainCapabilitiesFlags:
>> + *
>> + * Domain capabilities flags.
>> + *
>> + * Since: 10.10.0
>> + */
>> +typedef enum {
>> + /* Report host model with deprecated features disabled. (Since:
>> 10.10.0) */
>> + VIR_CONNECT_GET_DOMAIN_CAPABILITIES_DISABLE_DEPRECATED_FEATURES =
>> (1 << 0),
>> +} virConnectGetDomainCapabilitiesFlags;
>> +
>> char * virConnectGetDomainCapabilities(virConnectPtr conn,
>> const char *emulatorbin,
>> const char *arch,
>> diff --git a/src/libvirt-domain.c b/src/libvirt-domain.c
>> index 7c6b93963c..e8e5379672 100644
>> --- a/src/libvirt-domain.c
>> +++ b/src/libvirt-domain.c
>> @@ -12166,7 +12166,7 @@ virDomainSetUserPassword(virDomainPtr dom,
>> * @arch: domain architecture
>> * @machine: machine type
>> * @virttype: virtualization type
>> - * @flags: extra flags; not used yet, so callers should always pass 0
>> + * @flags: extra flags; bitwise-OR of
>> virConnectGetDomainCapabilitiesFlags
>> *
>> * Prior creating a domain (for instance via virDomainCreateXML
>> * or virDomainDefineXML) it may be suitable to know what the
>> diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
>> index 50905750fb..0701b2f4b0 100644
>> --- a/src/qemu/qemu_capabilities.c
>> +++ b/src/qemu/qemu_capabilities.c
>> @@ -3326,6 +3326,26 @@ virQEMUCapsGetCPUFeatures(virQEMUCaps *qemuCaps,
>> }
>> +void
>> +virQEMUCapsUpdateCPUDeprecatedFeatures(virQEMUCaps *qemuCaps,
>> + virDomainVirtType virtType,
>> + virCPUDef *cpu)
>> +{
>> + qemuMonitorCPUModelInfo *modelInfo;
>> + size_t i;
>> +
>> + modelInfo = virQEMUCapsGetCPUModelInfo(qemuCaps, virtType);
>> +
>> + if (!modelInfo || !modelInfo->deprecated_props)
>> + return;
>> +
>> + for (i = 0; i < g_strv_length(modelInfo->deprecated_props); i++) {
>> + virCPUDefUpdateFeature(cpu, modelInfo->deprecated_props[i],
>> + VIR_CPU_FEATURE_DISABLE);
>> + }
>> +}
>> +
>> +
>> struct tpmTypeToCaps {
>> int type;
>> virQEMUCapsFlags caps;
>> diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
>> index 8347fd7fbb..6bfe99fce4 100644
>> --- a/src/qemu/qemu_capabilities.h
>> +++ b/src/qemu/qemu_capabilities.h
>> @@ -764,6 +764,9 @@ int virQEMUCapsGetCPUFeatures(virQEMUCaps *qemuCaps,
>> virDomainVirtType virtType,
>> bool migratable,
>> char ***features);
>> +void virQEMUCapsUpdateCPUDeprecatedFeatures(virQEMUCaps *qemuCaps,
>> + virDomainVirtType virtType,
>> + virCPUDef *cpu);
>> virDomainVirtType virQEMUCapsGetVirtType(virQEMUCaps *qemuCaps);
>> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
>> index 5b9c55f704..86ab0bd39a 100644
>> --- a/src/qemu/qemu_driver.c
>> +++ b/src/qemu/qemu_driver.c
>> @@ -16521,7 +16521,8 @@ qemuConnectGetDomainCapabilities(virConnectPtr
>> conn,
>> virDomainVirtType virttype;
>> g_autoptr(virDomainCaps) domCaps = NULL;
>> - virCheckFlags(0, NULL);
>> +
>> virCheckFlags(VIR_CONNECT_GET_DOMAIN_CAPABILITIES_DISABLE_DEPRECATED_FEATURES,
>> + NULL);
>> if (virConnectGetDomainCapabilitiesEnsureACL(conn) < 0)
>> return NULL;
>> @@ -16540,6 +16541,11 @@
>> qemuConnectGetDomainCapabilities(virConnectPtr conn,
>> arch,
>> virttype)))
>> return NULL;
>> + if (flags &
>> VIR_CONNECT_GET_DOMAIN_CAPABILITIES_DISABLE_DEPRECATED_FEATURES) {
>> + virQEMUCapsUpdateCPUDeprecatedFeatures(qemuCaps, virttype,
>> + domCaps->cpu.hostModel);
>> + }
>> +
>> return virDomainCapsFormat(domCaps);
>> }
>> diff --git a/tools/virsh-host.c b/tools/virsh-host.c
>> index 2fe64e415f..f4e7324f42 100644
>> --- a/tools/virsh-host.c
>> +++ b/tools/virsh-host.c
>> @@ -114,6 +114,10 @@ static const vshCmdOptDef opts_domcapabilities[] = {
>> .type = VSH_OT_BOOL,
>> .help = N_("wrap xpath results in an common root element"),
>> },
>> + {.name = "disable-deprecated-features",
>> + .type = VSH_OT_BOOL,
>> + .help = N_("report host CPU model with deprecated features
>> disabled"),
>> + },
>> {.name = NULL}
>> };
>> @@ -126,10 +130,13 @@ cmdDomCapabilities(vshControl *ctl, const vshCmd
>> *cmd)
>> const char *arch = NULL;
>> const char *machine = NULL;
>> const char *xpath = NULL;
>> - const unsigned int flags = 0; /* No flags so far */
>> + unsigned int flags = 0;
>> bool wrap = vshCommandOptBool(cmd, "wrap");
>> virshControl *priv = ctl->privData;
>> + if (vshCommandOptBool(cmd, "disable-deprecated-features"))
>> + flags |=
>> VIR_CONNECT_GET_DOMAIN_CAPABILITIES_DISABLE_DEPRECATED_FEATURES;
>> +
>> if (vshCommandOptString(ctl, cmd, "virttype", &virttype) < 0 ||
>> vshCommandOptString(ctl, cmd, "emulatorbin", &emulatorbin) <
>> 0 ||
>> vshCommandOptString(ctl, cmd, "arch", &arch) < 0 ||
>
>
--
Mit freundlichen Grüßen/Kind regards
Boris Fiuczynski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Wolfgang Wendt
Geschäftsführung: David Faller
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
4 months, 1 week
[PATCH v2 0/6] network: fix dhcp response packet checksums on virtual networks
by Laine Stump
Patch 6/6 explains the problem and how these patches fix it. Assuming
no problems are found (none so far) this should go into 10.10.0, as it
solves a regression caused by switching the network driver to the
nftables backend.
There was a prior attempt at fixing this that was accepted, pushed,
bugs were discovered, and it was reverted (see Patch 6/6 for
details). This will hopefully be the final attempt.
The differences from V1 are:
* use a single "flags" argument rather than 3 bools when calling
virNetDevBandwidthSet() (Patch 1/5 turned into 1/6 & 2/6)
* be more lenient about what constitutes a "match" when looking at the
output of "tc qdisc show" (Patch 3/5 turned into 4/6
* call the new virFirewall layer "tc" rather than "raw", making it
specific to "tc" (Patch 4/5 turned into 5/6)
There may still be some disagreement about putting the tc commands in
the virFirewall, but I wanted to get this sent to save time in case my
argument was convincing :-)
Laine Stump (6):
util: use a single flags arg for virNetDevBandwidthSet(), not multiple
bools
util: make it optional to clear existing tc qdiscs/filters in
virNetDevBandwidthSet()
util: put the command that adds a tx filter qdisc into a separate
function
util: don't re-add the qdisc used for tx filters if it already exists
util: add new "tc" layer for virFirewallCmd objects
network: add tc filter rule to nftables backend to fix checksum of
DHCP responses
src/libvirt_private.syms | 1 +
src/lxc/lxc_driver.c | 8 +-
src/lxc/lxc_process.c | 8 +-
src/network/bridge_driver.c | 10 +-
src/network/network_nftables.c | 69 +++++++++++
src/qemu/qemu_command.c | 11 +-
src/qemu/qemu_driver.c | 29 ++---
src/qemu/qemu_hotplug.c | 22 +++-
src/util/virfirewall.c | 66 +++++++----
src/util/virfirewall.h | 1 +
src/util/virfirewalld.c | 1 +
src/util/virnetdevbandwidth.c | 110 ++++++++++++++----
src/util/virnetdevbandwidth.h | 15 ++-
.../forward-dev-linux.nftables | 40 +++++++
.../isolated-linux.nftables | 40 +++++++
.../nat-default-linux.nftables | 40 +++++++
.../nat-ipv6-linux.nftables | 40 +++++++
.../nat-ipv6-masquerade-linux.nftables | 40 +++++++
.../nat-many-ips-linux.nftables | 40 +++++++
.../nat-no-dhcp-linux.nftables | 40 +++++++
.../nat-port-range-ipv6-linux.nftables | 40 +++++++
.../nat-port-range-linux.nftables | 40 +++++++
.../nat-tftp-linux.nftables | 40 +++++++
.../route-default-linux.nftables | 40 +++++++
tests/virnetdevbandwidthtest.c | 12 +-
25 files changed, 724 insertions(+), 79 deletions(-)
--
2.47.0
4 months, 1 week
[PATCH 0/5] network: fix dhcp response packet checksums on virtual networks
by Laine Stump
Patch 4/4 explains the problem and how these patches fix it. Assuming
no problems are found (none so far) this should go into 10.10.0, as it
solves a regression caused by switching the network driver to the
nftables backend.
There was a prior attempt at fixing this that was accepted, pushed,
bugs were discovered, and it was reverted (see Patch 4/4 for details). This will hopefully be the final attempt.
Please test with as many different guests as possible, both with
nftables backend and iptables backend, and using different guest
interface types, etc.
Laine Stump (5):
util: make it optional to clear existing tc qdiscs/filters in
virNetDevBandwidthSet()
util: put the command that adds a tx filter qdisc into a separate
function
util: don't re-add the qdisc used for tx filters if it already exists
util: add new "raw" layer for virFirewallCmd objects
network: add tc filter rule to nftables backend to fix checksum of
DHCP responses
src/libvirt_private.syms | 1 +
src/lxc/lxc_driver.c | 2 +-
src/lxc/lxc_process.c | 2 +-
src/network/bridge_driver.c | 4 +-
src/network/network_nftables.c | 69 +++++++++++++++++
src/qemu/qemu_command.c | 2 +-
src/qemu/qemu_driver.c | 3 +-
src/qemu/qemu_hotplug.c | 4 +-
src/util/virfirewall.c | 74 ++++++++++++-------
src/util/virfirewall.h | 1 +
src/util/virfirewalld.c | 1 +
src/util/virnetdevbandwidth.c | 70 ++++++++++++++++--
src/util/virnetdevbandwidth.h | 4 +
.../forward-dev-linux.nftables | 40 ++++++++++
.../isolated-linux.nftables | 40 ++++++++++
.../nat-default-linux.nftables | 40 ++++++++++
.../nat-ipv6-linux.nftables | 40 ++++++++++
.../nat-ipv6-masquerade-linux.nftables | 40 ++++++++++
.../nat-many-ips-linux.nftables | 40 ++++++++++
.../nat-no-dhcp-linux.nftables | 40 ++++++++++
.../nat-port-range-ipv6-linux.nftables | 40 ++++++++++
.../nat-port-range-linux.nftables | 40 ++++++++++
.../nat-tftp-linux.nftables | 40 ++++++++++
.../route-default-linux.nftables | 40 ++++++++++
tests/virnetdevbandwidthtest.c | 5 +-
25 files changed, 639 insertions(+), 43 deletions(-)
--
2.47.0
4 months, 1 week
[PATCH v3 00/15] Implement support for QCOW2 data files
by Nikolai Barybin
Hello everyone!
With help of Peter's comprehensive review I finally present 3rd version
of this series.
Changes since last revision:
- minor code improvements including memory leaks fixes
- splitted and regrouped some patches for more logical structure
- fixed issue with erroneous disk with data file detatch
- completely rewritten tests
- added some piece of documentation
Nikolai Barybin (15):
conf: add data-file feature and related fields to virStorageSource
Add VIR_STORAGE_FILE_FEATURE_DATA_FILE to virStorageFileFeature enum
conf: schemas: add data-file store to domain rng schema
conf: implement XML parsing/formating for dataFileStore
storage file: add getDataFile function to FileTypeInfo
storage file: add qcow2 data-file path parsing from header
storage file: fill in src->dataFileStore during file probe
security: DAC: handle qcow2 data-file on image label set/restore
security: selinux: handle qcow2 data-file on image label set/restore
security: apparmor: handle qcow2 data-file
qemu: put data-file path to VM's cgroup and namespace
qemu: factor out qemuDomainPrepareStorageSource()
qemu: enable basic qcow2 data-file feature support
tests: add qcow2 data-file tests
docs: formatdomain: describe dataFileStore element of disk
docs/formatdomain.rst | 45 +++++++-
src/conf/domain_conf.c | 100 ++++++++++++++++++
src/conf/domain_conf.h | 13 +++
src/conf/schemas/domaincommon.rng | 15 +++
src/conf/storage_source_conf.c | 11 ++
src/conf/storage_source_conf.h | 5 +
src/qemu/qemu_block.c | 14 +++
src/qemu/qemu_cgroup.c | 13 ++-
src/qemu/qemu_command.c | 5 +
src/qemu/qemu_domain.c | 50 ++++++---
src/qemu/qemu_namespace.c | 7 ++
src/security/security_dac.c | 27 ++++-
src/security/security_selinux.c | 27 ++++-
src/security/virt-aa-helper.c | 4 +
src/storage_file/storage_file_probe.c | 78 ++++++++++----
src/storage_file/storage_source.c | 39 +++++++
src/storage_file/storage_source.h | 4 +
.../qcow2-data-file-in.xml | 86 +++++++++++++++
.../qcow2-data-file-out.xml | 86 +++++++++++++++
tests/qemuxmlactivetest.c | 2 +
...sk-qcow2-datafile-store.x86_64-latest.args | 51 +++++++++
...isk-qcow2-datafile-store.x86_64-latest.xml | 81 ++++++++++++++
.../disk-qcow2-datafile-store.xml | 67 ++++++++++++
tests/qemuxmlconftest.c | 1 +
tests/virstoragetest.c | 98 +++++++++++++++++
tests/virstoragetestdata/out/qcow2-data_file | 20 ++++
.../out/qcow2-qcow2_qcow2-qcow2-data_file | 31 ++++++
27 files changed, 941 insertions(+), 39 deletions(-)
create mode 100644 tests/qemustatusxml2xmldata/qcow2-data-file-in.xml
create mode 100644 tests/qemustatusxml2xmldata/qcow2-data-file-out.xml
create mode 100644 tests/qemuxmlconfdata/disk-qcow2-datafile-store.x86_64-latest.args
create mode 100644 tests/qemuxmlconfdata/disk-qcow2-datafile-store.x86_64-latest.xml
create mode 100644 tests/qemuxmlconfdata/disk-qcow2-datafile-store.xml
create mode 100644 tests/virstoragetestdata/out/qcow2-data_file
create mode 100644 tests/virstoragetestdata/out/qcow2-qcow2_qcow2-qcow2-data_file
--
2.43.5
4 months, 2 weeks
[PATCH] docs: formatsecret: Fix an example of secret-set-value
by Han Han
The previous example will cause the error like:
error: Options --file and --base64 are mutually exclusive
Reported-by: Yanqiu Zhang <yanqzhan(a)redhat.com>
Signed-off-by: Han Han <hhan(a)redhat.com>
---
docs/formatsecret.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/formatsecret.rst b/docs/formatsecret.rst
index aeeb67610d..606a9cc587 100644
--- a/docs/formatsecret.rst
+++ b/docs/formatsecret.rst
@@ -318,7 +318,7 @@ be omitted if the file contents are base64-encoded.
::
- # virsh secret-set-value 6dd3e4a5-1d76-44ce-961f-f119f5aad935 --file --plain secretinfile
+ # virsh secret-set-value 6dd3e4a5-1d76-44ce-961f-f119f5aad935 --file secretinfile --plain
Secret value set
**WARNING** The following approach is **insecure** and deprecated. The secret
--
2.47.0
4 months, 2 weeks
Container build failures for cross-builds on debian-11
by Martin Kletzander
Weekly container builds fail for almost 2 months now (last passed
container build was on 2nd of September) due to debian-11 being probably
broken when installing cross-arch packages. Debian 12 was released at
the 10th of June 2023, so we support debian-11 for 7 more months. But
the cross-builds are probably going to fail for all those 7 months.
Since that spoils the view of the pipelines I would suggest we remove
the cross-architecture builds for debian-11 since we're still testing
them on debian-12 and that works nicely. We would still keep x86_64 and
i686 debian-11 builds there of course. Is anyone opposed to that or is
there any clear issue with the above suggestion?
4 months, 2 weeks
