11:25 a.m.
Now that it's officially out, we can refresh existing capabilities
created from git snapshots and introduce them for the architectures
where they were missing altogether.
This series covers all architectures except for s390x, to which I
don't have convenient access: Pino promised me he'd take care of that
one in a few days.
As usual for this kind of series, most patches have been snipped with
extreme prejudice in order to make them small enough that they
wouldn't end up in the moderation queue: the unabridged version can
be found at
https://github.com/andreabolognani/libvirt
in the 'qemucaps-4.0.0' branch.
It'd be great if we could sneak these in during the freeze so that I
won't have to possibly regenerate them again after the post-release
merge flood ;)
Andrea Bolognani (5):
tests: Refresh capabilities for QEMU 4.0.0 on x86_64
tests: Refresh capabilities for QEMU 4.0.0 on riscv32
tests: Refresh capabilities for QEMU 4.0.0 on riscv64
tests: Add capabilities for QEMU 4.0.0 on aarch64
tests: Add capabilities for QEMU 4.0.0 on ppc64
.../qemu_4.0.0.x86_64.xml | 3 +-
...v32.replies => caps_4.0.0.aarch64.replies} | 6997 ++--
.../caps_4.0.0.aarch64.xml | 310 +
...scv32.replies => caps_4.0.0.ppc64.replies} | 29886 ++++++++++------
.../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1077 +
.../caps_4.0.0.riscv32.replies | 10 +-
.../caps_4.0.0.riscv32.xml | 4 +-
.../caps_4.0.0.riscv64.replies | 10 +-
.../caps_4.0.0.riscv64.xml | 4 +-
.../caps_4.0.0.x86_64.replies | 3331 +-
.../caps_4.0.0.x86_64.xml | 38 +-
...arch64-os-firmware-efi.aarch64-latest.args | 2 +-
.../aarch64-virt-graphics.aarch64-latest.args | 2 +-
.../aarch64-virt-headless.aarch64-latest.args | 2 +-
14 files changed, 25862 insertions(+), 15814 deletions(-)
copy tests/qemucapabilitiesdata/{caps_4.0.0.riscv32.replies =>
caps_4.0.0.aarch64.replies} (86%)
create mode 100644 tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml
copy tests/qemucapabilitiesdata/{caps_4.0.0.riscv32.replies =>
caps_4.0.0.ppc64.replies} (71%)
create mode 100644 tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml
--
2.20.1
11:25 a.m.
New subject: [libvirt] [PATCH 1/5] tests: Refresh capabilities for QEMU 4.0.0 on x86_64
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
This one was generated very early, so there is a significant number
of changes. A few capabilities end up being missing, but I think
that's mostly because I'm using an i7 rather than a Xeon; overall the
changes seem benign, especially considering that none of the .args
ends up being modified.
.../qemu_4.0.0.x86_64.xml | 3 +-
.../caps_4.0.0.x86_64.replies | 3331 +++++++++--------
.../caps_4.0.0.x86_64.xml | 38 +-
3 files changed, 1796 insertions(+), 1576 deletions(-)
diff --git a/tests/domaincapsschemadata/qemu_4.0.0.x86_64.xml
b/tests/domaincapsschemadata/qemu_4.0.0.x86_64.xml
index 42d8949e61..31ef094e21 100644
--- a/tests/domaincapsschemadata/qemu_4.0.0.x86_64.xml
+++ b/tests/domaincapsschemadata/qemu_4.0.0.x86_64.xml
@@ -33,11 +33,12 @@
<model fallback='forbid'>Skylake-Client-IBRS</model>
<vendor>Intel</vendor>
<feature policy='require' name='ss'/>
+ <feature policy='require' name='vmx'/>
<feature policy='require' name='hypervisor'/>
<feature policy='require' name='tsc_adjust'/>
<feature policy='require' name='clflushopt'/>
<feature policy='require' name='umip'/>
- <feature policy='require' name='arch-capabilities'/>
+ <feature policy='require' name='stibp'/>
<feature policy='require' name='ssbd'/>
<feature policy='require' name='xsaves'/>
<feature policy='require' name='pdpe1gb'/>
diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.replies
b/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.replies
index aa9ee38c80..ca56344ae7 100644
--- a/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.replies
+++ b/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.replies
@@ -17,11 +17,11 @@
{
"return": {
"qemu": {
- "micro": 50,
- "minor": 1,
- "major": 3
+ "micro": 0,
+ "minor": 0,
+ "major": 4
},
- "package": "v3.1.0-1445-ga61faa3d02"
+ "package": "v4.0.0"
},
"id": "libvirt-2"
}
[...]
diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml
b/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml
index f4be7017fe..679e1b13d4 100644
--- a/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml
+++ b/tests/qemucapabilitiesdata/caps_4.0.0.x86_64.xml
@@ -202,10 +202,10 @@
<flag name='virtio-pci-non-transitional'/>
<flag name='overcommit'/>
<flag name='query-current-machine'/>
- <version>3001050</version>
+ <version>4000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>43100758</microcodeVersion>
- <package>v3.1.0-1445-ga61faa3d02</package>
+ <package>v4.0.0</package>
<arch>x86_64</arch>
<hostCPU type='kvm' model='base' migratability='yes'>
<property name='phys-bits' type='number' value='0'/>
@@ -226,6 +226,7 @@
<property name='hv-frequencies' type='boolean'
value='false'/>
<property name='tsc-frequency' type='number'
value='0'/>
<property name='xd' type='boolean' value='true'
migratable='yes'/>
+ <property name='x-intel-pt-auto-level' type='boolean'
value='true' migratable='yes'/>
<property name='hv-vendor-id' type='string' value=''/>
<property name='kvm-asyncpf' type='boolean' value='true'
migratable='yes'/>
<property name='kvm_asyncpf' type='boolean' value='true'
migratable='yes'/>
@@ -267,7 +268,7 @@
<property name='3dnowprefetch' type='boolean' value='true'
migratable='yes'/>
<property name='avx512vbmi2' type='boolean'
value='false'/>
<property name='cr8legacy' type='boolean'
value='false'/>
- <property name='stibp' type='boolean' value='false'/>
+ <property name='stibp' type='boolean' value='true'
migratable='yes'/>
<property name='cpuid-0xb' type='boolean' value='true'
migratable='yes'/>
<property name='xcrypt-en' type='boolean'
value='false'/>
<property name='kvm_pv_eoi' type='boolean' value='true'
migratable='yes'/>
@@ -351,7 +352,7 @@
<property name='nodeid_msr' type='boolean'
value='false'/>
<property name='pdcm' type='boolean' value='false'/>
<property name='movbe' type='boolean' value='true'
migratable='yes'/>
- <property name='model' type='number' value='94'/>
+ <property name='model' type='number' value='142'/>
<property name='nrip_save' type='boolean'
value='false'/>
<property name='nrip-save' type='boolean'
value='false'/>
<property name='kvm_pv_unhalt' type='boolean' value='true'
migratable='yes'/>
@@ -364,9 +365,8 @@
<property name='fma' type='boolean' value='true'
migratable='yes'/>
<property name='cx16' type='boolean' value='true'
migratable='yes'/>
<property name='de' type='boolean' value='true'
migratable='yes'/>
- <property name='pconfig' type='boolean'
value='false'/>
<property name='enforce' type='boolean'
value='false'/>
- <property name='stepping' type='number' value='3'/>
+ <property name='stepping' type='number' value='10'/>
<property name='xsave' type='boolean' value='true'
migratable='yes'/>
<property name='clflush' type='boolean' value='true'
migratable='yes'/>
<property name='skinit' type='boolean' value='false'/>
@@ -440,7 +440,7 @@
<property name='avx512er' type='boolean'
value='false'/>
<property name='pmm-en' type='boolean' value='false'/>
<property name='pcid' type='boolean' value='true'
migratable='yes'/>
- <property name='arch-capabilities' type='boolean'
value='true' migratable='no'/>
+ <property name='arch-capabilities' type='boolean'
value='false'/>
<property name='3dnow' type='boolean' value='false'/>
<property name='erms' type='boolean' value='true'
migratable='yes'/>
<property name='lahf-lm' type='boolean' value='true'
migratable='yes'/>
@@ -461,7 +461,7 @@
<property name='rdrand' type='boolean' value='true'
migratable='yes'/>
<property name='rdseed' type='boolean' value='true'
migratable='yes'/>
<property name='avx512-4vnniw' type='boolean'
value='false'/>
- <property name='vmx' type='boolean' value='false'/>
+ <property name='vmx' type='boolean' value='true'
migratable='yes'/>
<property name='vme' type='boolean' value='true'
migratable='yes'/>
<property name='dtes64' type='boolean' value='false'/>
<property name='mtrr' type='boolean' value='true'
migratable='yes'/>
@@ -472,7 +472,7 @@
<property name='wdt' type='boolean' value='false'/>
<property name='pause_filter' type='boolean'
value='false'/>
<property name='sha-ni' type='boolean' value='false'/>
- <property name='model-id' type='string' value='Intel(R)
Xeon(R) CPU E3-1245 v5 @ 3.50GHz'/>
+ <property name='model-id' type='string' value='Intel(R)
Core(TM) i7-8650U CPU @ 1.90GHz'/>
<property name='abm' type='boolean' value='true'
migratable='yes'/>
<property name='avx512pf' type='boolean'
value='false'/>
<property name='xstore-en' type='boolean'
value='false'/>
@@ -496,6 +496,7 @@
<property name='hv-frequencies' type='boolean'
value='false'/>
<property name='tsc-frequency' type='number'
value='0'/>
<property name='xd' type='boolean' value='true'
migratable='yes'/>
+ <property name='x-intel-pt-auto-level' type='boolean'
value='true' migratable='yes'/>
<property name='hv-vendor-id' type='string' value=''/>
<property name='kvm-asyncpf' type='boolean'
value='false'/>
<property name='kvm_asyncpf' type='boolean'
value='false'/>
@@ -634,7 +635,6 @@
<property name='fma' type='boolean' value='false'/>
<property name='cx16' type='boolean' value='true'
migratable='yes'/>
<property name='de' type='boolean' value='true'
migratable='yes'/>
- <property name='pconfig' type='boolean'
value='false'/>
<property name='enforce' type='boolean'
value='false'/>
<property name='stepping' type='number' value='3'/>
<property name='xsave' type='boolean' value='true'
migratable='yes'/>
@@ -849,13 +849,11 @@
<blocker name='avx512f'/>
<blocker name='avx512dq'/>
<blocker name='clwb'/>
- <blocker name='intel-pt'/>
<blocker name='avx512cd'/>
<blocker name='avx512bw'/>
<blocker name='avx512vl'/>
<blocker name='avx512vbmi'/>
<blocker name='pku'/>
- <blocker name=''/>
<blocker name='avx512vbmi2'/>
<blocker name='gfni'/>
<blocker name='vaes'/>
@@ -864,7 +862,6 @@
<blocker name='avx512bitalg'/>
<blocker name='avx512-vpopcntdq'/>
<blocker name='la57'/>
- <blocker name='pconfig'/>
<blocker name='wbnoinvd'/>
<blocker name='avx512f'/>
<blocker name='avx512f'/>
@@ -872,10 +869,8 @@
<blocker name='pku'/>
</cpu>
<cpu type='kvm' name='Icelake-Client' usable='no'>
- <blocker name='intel-pt'/>
<blocker name='avx512vbmi'/>
<blocker name='pku'/>
- <blocker name=''/>
<blocker name='avx512vbmi2'/>
<blocker name='gfni'/>
<blocker name='vaes'/>
@@ -918,12 +913,10 @@
<blocker name='avx512f'/>
<blocker name='avx512dq'/>
<blocker name='clwb'/>
- <blocker name='intel-pt'/>
<blocker name='avx512cd'/>
<blocker name='avx512bw'/>
<blocker name='avx512vl'/>
<blocker name='pku'/>
- <blocker name=''/>
<blocker name='avx512vnni'/>
<blocker name='avx512f'/>
<blocker name='avx512f'/>
@@ -1122,13 +1115,11 @@
<blocker name='avx512f'/>
<blocker name='avx512dq'/>
<blocker name='rdseed'/>
- <blocker name='intel-pt'/>
<blocker name='avx512cd'/>
<blocker name='avx512bw'/>
<blocker name='avx512vl'/>
<blocker name='avx512vbmi'/>
<blocker name='umip'/>
- <blocker name=''/>
<blocker name='avx512vbmi2'/>
<blocker name='gfni'/>
<blocker name='vaes'/>
@@ -1136,7 +1127,6 @@
<blocker name='avx512vnni'/>
<blocker name='avx512bitalg'/>
<blocker name='avx512-vpopcntdq'/>
- <blocker name='pconfig'/>
<blocker name='spec-ctrl'/>
<blocker name='ssbd'/>
<blocker name='3dnowprefetch'/>
@@ -1156,10 +1146,8 @@
<blocker name='invpcid'/>
<blocker name='rtm'/>
<blocker name='rdseed'/>
- <blocker name='intel-pt'/>
<blocker name='avx512vbmi'/>
<blocker name='umip'/>
- <blocker name=''/>
<blocker name='avx512vbmi2'/>
<blocker name='gfni'/>
<blocker name='vaes'/>
@@ -1272,11 +1260,9 @@
<blocker name='avx512f'/>
<blocker name='avx512dq'/>
<blocker name='rdseed'/>
- <blocker name='intel-pt'/>
<blocker name='avx512cd'/>
<blocker name='avx512bw'/>
<blocker name='avx512vl'/>
- <blocker name=''/>
<blocker name='avx512vnni'/>
<blocker name='spec-ctrl'/>
<blocker name='ssbd'/>
@@ -1352,6 +1338,7 @@
<machine name='pc-i440fx-2.9' hotplugCpus='yes'
maxCpus='255'/>
<machine name='pc-i440fx-2.6' hotplugCpus='yes'
maxCpus='255'/>
<machine name='pc-i440fx-2.7' hotplugCpus='yes'
maxCpus='255'/>
+ <machine name='xenfv' hotplugCpus='yes' maxCpus='128'/>
<machine name='pc-i440fx-2.3' hotplugCpus='yes'
maxCpus='255'/>
<machine name='pc-i440fx-2.4' hotplugCpus='yes'
maxCpus='255'/>
<machine name='pc-i440fx-2.5' hotplugCpus='yes'
maxCpus='255'/>
@@ -1362,6 +1349,7 @@
<machine name='pc-q35-2.11' hotplugCpus='yes'
maxCpus='288'/>
<machine name='pc-q35-2.12' hotplugCpus='yes'
maxCpus='288'/>
<machine name='pc-q35-3.0' hotplugCpus='yes'
maxCpus='288'/>
+ <machine name='xenpv' maxCpus='1'/>
<machine name='pc-q35-2.10' hotplugCpus='yes'
maxCpus='288'/>
<machine name='pc-i440fx-1.7' hotplugCpus='yes'
maxCpus='255'/>
<machine name='pc-q35-2.9' hotplugCpus='yes'
maxCpus='288'/>
@@ -1379,8 +1367,8 @@
<machine name='pc-q35-2.4' hotplugCpus='yes'
maxCpus='255'/>
<machine name='pc-q35-2.5' hotplugCpus='yes'
maxCpus='255'/>
<machine name='pc-q35-2.6' hotplugCpus='yes'
maxCpus='255'/>
- <machine name='pc-i440fx-2.10' hotplugCpus='yes'
maxCpus='255'/>
<machine name='pc-i440fx-1.4' hotplugCpus='yes'
maxCpus='255'/>
+ <machine name='pc-i440fx-2.10' hotplugCpus='yes'
maxCpus='255'/>
<machine name='pc-0.12' hotplugCpus='yes'
maxCpus='255'/>
<machine name='pc-q35-4.0' alias='q35' hotplugCpus='yes'
maxCpus='288'/>
</qemuCaps>
--
2.20.1
11:25 a.m.
New subject: [libvirt] [PATCH 2/5] tests: Refresh capabilities for QEMU 4.0.0 on riscv32
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
tests/qemucapabilitiesdata/caps_4.0.0.riscv32.replies | 10 +++++-----
tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.riscv32.replies
b/tests/qemucapabilitiesdata/caps_4.0.0.riscv32.replies
index c7dac44289..9671d6f914 100644
--- a/tests/qemucapabilitiesdata/caps_4.0.0.riscv32.replies
+++ b/tests/qemucapabilitiesdata/caps_4.0.0.riscv32.replies
@@ -17,11 +17,11 @@
{
"return": {
"qemu": {
- "micro": 91,
- "minor": 1,
- "major": 3
+ "micro": 0,
+ "minor": 0,
+ "major": 4
},
- "package": "v4.0.0-rc1-33-ga04d91c701"
+ "package": "v4.0.0"
},
"id": "libvirt-2"
}
@@ -10395,7 +10395,7 @@
"type": "310"
},
{
- "name": "last_mode",
+ "name": "last-mode",
"type": "310"
},
{
diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml
b/tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml
index 2b6aa7b371..e987cdd415 100644
--- a/tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml
+++ b/tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml
@@ -164,10 +164,10 @@
<flag name='virtio-pci-non-transitional'/>
<flag name='overcommit'/>
<flag name='query-current-machine'/>
- <version>3001091</version>
+ <version>4000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>0</microcodeVersion>
- <package>v4.0.0-rc1-33-ga04d91c701</package>
+ <package>v4.0.0</package>
<arch>riscv32</arch>
<machine name='spike_v1.10' maxCpus='1' default='yes'/>
<machine name='virt' maxCpus='8'/>
--
2.20.1
3:15 a.m.
New subject: [libvirt] [PATCH 2/5] tests: Refresh capabilities for QEMU 4.0.0 on riscv32
On Mon, Apr 29, 2019 at 18:25:52 +0200, Andrea Bolognani wrote:
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
tests/qemucapabilitiesdata/caps_4.0.0.riscv32.replies | 10 +++++-----
tests/qemucapabilitiesdata/caps_4.0.0.riscv32.xml | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
ACK
11:25 a.m.
New subject: [libvirt] [PATCH 3/5] tests: Refresh capabilities for QEMU 4.0.0 on riscv64
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
tests/qemucapabilitiesdata/caps_4.0.0.riscv64.replies | 10 +++++-----
tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.riscv64.replies
b/tests/qemucapabilitiesdata/caps_4.0.0.riscv64.replies
index 6fda8ad2d2..0ca4484781 100644
--- a/tests/qemucapabilitiesdata/caps_4.0.0.riscv64.replies
+++ b/tests/qemucapabilitiesdata/caps_4.0.0.riscv64.replies
@@ -17,11 +17,11 @@
{
"return": {
"qemu": {
- "micro": 91,
- "minor": 1,
- "major": 3
+ "micro": 0,
+ "minor": 0,
+ "major": 4
},
- "package": "v4.0.0-rc1-33-ga04d91c701"
+ "package": "v4.0.0"
},
"id": "libvirt-2"
}
@@ -10395,7 +10395,7 @@
"type": "310"
},
{
- "name": "last_mode",
+ "name": "last-mode",
"type": "310"
},
{
diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml
b/tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml
index 8c0965a634..e1a07dd945 100644
--- a/tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml
+++ b/tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml
@@ -164,10 +164,10 @@
<flag name='virtio-pci-non-transitional'/>
<flag name='overcommit'/>
<flag name='query-current-machine'/>
- <version>3001091</version>
+ <version>4000000</version>
<kvmVersion>0</kvmVersion>
<microcodeVersion>0</microcodeVersion>
- <package>v4.0.0-rc1-33-ga04d91c701</package>
+ <package>v4.0.0</package>
<arch>riscv64</arch>
<machine name='spike_v1.10' maxCpus='1' default='yes'/>
<machine name='virt' maxCpus='8'/>
--
2.20.1
3:15 a.m.
New subject: [libvirt] [PATCH 3/5] tests: Refresh capabilities for QEMU 4.0.0 on riscv64
On Mon, Apr 29, 2019 at 18:25:53 +0200, Andrea Bolognani wrote:
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
tests/qemucapabilitiesdata/caps_4.0.0.riscv64.replies | 10 +++++-----
tests/qemucapabilitiesdata/caps_4.0.0.riscv64.xml | 4 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
ACK
11:25 a.m.
New subject: [libvirt] [PATCH 4/5] tests: Add capabilities for QEMU 4.0.0 on aarch64
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
The changes in the .args file seem entirely justified by the fact
that those for aarch64-virt-headless and aarch64-virt-graphics use
the new command line option too.
.../caps_4.0.0.aarch64.replies | 19997 ++++++++++++++++
.../caps_4.0.0.aarch64.xml | 310 +
...arch64-os-firmware-efi.aarch64-latest.args | 2 +-
.../aarch64-virt-graphics.aarch64-latest.args | 2 +-
.../aarch64-virt-headless.aarch64-latest.args | 2 +-
5 files changed, 20310 insertions(+), 3 deletions(-)
create mode 100644 tests/qemucapabilitiesdata/caps_4.0.0.aarch64.replies
create mode 100644 tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml
diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.aarch64.replies
b/tests/qemucapabilitiesdata/caps_4.0.0.aarch64.replies
new file mode 100644
index 0000000000..fa092a409e
--- /dev/null
+++ b/tests/qemucapabilitiesdata/caps_4.0.0.aarch64.replies
@@ -0,0 +1,19997 @@
+{
+ "execute": "qmp_capabilities",
+ "id": "libvirt-1"
+}
+
+{
+ "return": {
+ },
+ "id": "libvirt-1"
+}
+
+{
+ "execute": "query-version",
+ "id": "libvirt-2"
+}
+
+{
+ "return": {
+ "qemu": {
+ "micro": 0,
+ "minor": 0,
+ "major": 4
+ },
+ "package": "v4.0.0"
+ },
+ "id": "libvirt-2"
+}
[...]
diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml
b/tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml
new file mode 100644
index 0000000000..7bcda0b402
--- /dev/null
+++ b/tests/qemucapabilitiesdata/caps_4.0.0.aarch64.xml
@@ -0,0 +1,310 @@
+<qemuCaps>
[...]
+ <version>4000000</version>
+ <kvmVersion>0</kvmVersion>
+ <microcodeVersion>61700758</microcodeVersion>
+ <package>v4.0.0</package>
+ <arch>aarch64</arch>
[...]
diff --git a/tests/qemuxml2argvdata/aarch64-os-firmware-efi.aarch64-latest.args
b/tests/qemuxml2argvdata/aarch64-os-firmware-efi.aarch64-latest.args
index c9f38e4796..9821e28358 100644
--- a/tests/qemuxml2argvdata/aarch64-os-firmware-efi.aarch64-latest.args
+++ b/tests/qemuxml2argvdata/aarch64-os-firmware-efi.aarch64-latest.args
@@ -19,7 +19,7 @@ readonly=on \
-drive file=/var/lib/libvirt/qemu/nvram/aarch64test_VARS.fd,if=pflash,\
format=raw,unit=1 \
-m 1024 \
--realtime mlock=off \
+-overcommit mem-lock=off \
-smp 1,sockets=1,cores=1,threads=1 \
-uuid 496d7ea8-9739-544b-4ebd-ef08be936e8b \
-display none \
diff --git a/tests/qemuxml2argvdata/aarch64-virt-graphics.aarch64-latest.args
b/tests/qemuxml2argvdata/aarch64-virt-graphics.aarch64-latest.args
index b61eb56a1f..7f18f5e9e8 100644
--- a/tests/qemuxml2argvdata/aarch64-virt-graphics.aarch64-latest.args
+++ b/tests/qemuxml2argvdata/aarch64-virt-graphics.aarch64-latest.args
@@ -18,7 +18,7 @@ readonly=on \
-drive file=/var/lib/libvirt/qemu/nvram/guest_VARS.fd,if=pflash,format=raw,\
unit=1 \
-m 4096 \
--realtime mlock=off \
+-overcommit mem-lock=off \
-smp 4,sockets=4,cores=1,threads=1 \
-uuid 33844184-97c0-4cc0-aa7d-206f5803530b \
-no-user-config \
diff --git a/tests/qemuxml2argvdata/aarch64-virt-headless.aarch64-latest.args
b/tests/qemuxml2argvdata/aarch64-virt-headless.aarch64-latest.args
index 62471e7f4b..cc1189031a 100644
--- a/tests/qemuxml2argvdata/aarch64-virt-headless.aarch64-latest.args
+++ b/tests/qemuxml2argvdata/aarch64-virt-headless.aarch64-latest.args
@@ -14,7 +14,7 @@ QEMU_AUDIO_DRV=none \
file=/tmp/lib/domain--1-guest/master-key.aes \
-machine virt,accel=tcg,usb=off,dump-guest-core=off,gic-version=2 \
-m 1024 \
--realtime mlock=off \
+-overcommit mem-lock=off \
-smp 1,sockets=1,cores=1,threads=1 \
-uuid 1ccfd97d-5eb4-478a-bbe6-88d254c16db7 \
-display none \
--
2.20.1
3:30 a.m.
New subject: [libvirt] [PATCH 4/5] tests: Add capabilities for QEMU 4.0.0 on aarch64
On Mon, Apr 29, 2019 at 18:25:54 +0200, Andrea Bolognani wrote:
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
The changes in the .args file seem entirely justified by the fact
that those for aarch64-virt-headless and aarch64-virt-graphics use
the new command line option too.
ACK
11:25 a.m.
New subject: [libvirt] [PATCH 5/5] tests: Add capabilities for QEMU 4.0.0 on ppc64
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
.../caps_4.0.0.ppc64.replies | 23960 ++++++++++++++++
.../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1077 +
2 files changed, 25037 insertions(+)
create mode 100644 tests/qemucapabilitiesdata/caps_4.0.0.ppc64.replies
create mode 100644 tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml
diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.ppc64.replies
b/tests/qemucapabilitiesdata/caps_4.0.0.ppc64.replies
new file mode 100644
index 0000000000..e1bc78bfae
--- /dev/null
+++ b/tests/qemucapabilitiesdata/caps_4.0.0.ppc64.replies
@@ -0,0 +1,23960 @@
+{
+ "execute": "qmp_capabilities",
+ "id": "libvirt-1"
+}
+
+{
+ "return": {
+ },
+ "id": "libvirt-1"
+}
+
+{
+ "execute": "query-version",
+ "id": "libvirt-2"
+}
+
+{
+ "return": {
+ "qemu": {
+ "micro": 0,
+ "minor": 0,
+ "major": 4
+ },
+ "package": "v4.0.0"
+ },
+ "id": "libvirt-2"
+}
[...]
diff --git a/tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml
b/tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml
new file mode 100644
index 0000000000..9c4e6583ec
--- /dev/null
+++ b/tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml
@@ -0,0 +1,1077 @@
+<qemuCaps>
[...]
+ <version>4000000</version>
+ <kvmVersion>0</kvmVersion>
+ <microcodeVersion>42900758</microcodeVersion>
+ <package>v4.0.0</package>
+ <arch>ppc64</arch>
[...]
--
2.20.1
3:31 a.m.
New subject: [libvirt] [PATCH 5/5] tests: Add capabilities for QEMU 4.0.0 on ppc64
On Mon, Apr 29, 2019 at 18:25:55 +0200, Andrea Bolognani wrote:
Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
---
.../caps_4.0.0.ppc64.replies | 23960 ++++++++++++++++
.../qemucapabilitiesdata/caps_4.0.0.ppc64.xml | 1077 +
2 files changed, 25037 insertions(+)
create mode 100644 tests/qemucapabilitiesdata/caps_4.0.0.ppc64.replies
create mode 100644 tests/qemucapabilitiesdata/caps_4.0.0.ppc64.xml
ACK
6:55 a.m.
On Mon, Apr 29, 2019 at 06:25:50PM +0200, Andrea Bolognani wrote:
Now that it's officially out, we can refresh existing
capabilities
created from git snapshots and introduce them for the architectures
where they were missing altogether.
This series covers all architectures except for s390x, to which I
don't have convenient access: Pino promised me he'd take care of that
one in a few days.
As usual for this kind of series, most patches have been snipped with
extreme prejudice in order to make them small enough that they
wouldn't end up in the moderation queue: the unabridged version can
be found at
https://github.com/andreabolognani/libvirt
in the 'qemucaps-4.0.0' branch.
It'd be great if we could sneak these in during the freeze so that I
won't have to possibly regenerate them again after the post-release
merge flood ;)
Peter sent the same patch for x86_64 as well, there is one difference,
you also have all the Xen things enabled which would be nice to not
have it there since we don't care about it.
I acked Peter's patch so can you please re-post again with
--disable-xen appended to the configure of QEMU?
Pavel
7:44 a.m.
On Tue, 2019-04-30 at 13:55 +0200, Pavel Hrdina wrote:
On Mon, Apr 29, 2019 at 06:25:50PM +0200, Andrea Bolognani wrote:
> Now that it's officially out, we can refresh existing capabilities
> created from git snapshots and introduce them for the architectures
> where they were missing altogether.
>
> This series covers all architectures except for s390x, to which I
> don't have convenient access: Pino promised me he'd take care of that
> one in a few days.
>
> As usual for this kind of series, most patches have been snipped with
> extreme prejudice in order to make them small enough that they
> wouldn't end up in the moderation queue: the unabridged version can
> be found at
>
> https://github.com/andreabolognani/libvirt
>
> in the 'qemucaps-4.0.0' branch.
>
> It'd be great if we could sneak these in during the freeze so that I
> won't have to possibly regenerate them again after the post-release
> merge flood ;)
Peter sent the same patch for x86_64 as well, there is one difference,
you also have all the Xen things enabled which would be nice to not
have it there since we don't care about it.
I acked Peter's patch so can you please re-post again with
--disable-xen appended to the configure of QEMU?
We might not care in RHEL, but we certainly *do* care upstream.
More specifically, I built both QEMU and libvirt on Fedora 29 after
running 'dnf builddep' for the respective packages, so there should
be nothing enabled that would not be enabled in the Fedora packages:
in fact, I compared the replies and they're identical.
Additionally, if you check out the existing replies you'll see that
we had Xen support compiled into QEMU when we generated those for
versions 2.8, 2.9 and 2.10. And no, not all of those were provided
by me... You might actually be surprised when looking at the git
history for those files ;)
--
Andrea Bolognani / Red Hat / Virtualization
8:02 a.m.
On Tue, Apr 30, 2019 at 02:44:06PM +0200, Andrea Bolognani wrote:
On Tue, 2019-04-30 at 13:55 +0200, Pavel Hrdina wrote:
> On Mon, Apr 29, 2019 at 06:25:50PM +0200, Andrea Bolognani wrote:
> > Now that it's officially out, we can refresh existing capabilities
> > created from git snapshots and introduce them for the architectures
> > where they were missing altogether.
> >
> > This series covers all architectures except for s390x, to which I
> > don't have convenient access: Pino promised me he'd take care of that
> > one in a few days.
> >
> > As usual for this kind of series, most patches have been snipped with
> > extreme prejudice in order to make them small enough that they
> > wouldn't end up in the moderation queue: the unabridged version can
> > be found at
> >
> > https://github.com/andreabolognani/libvirt
> >
> > in the 'qemucaps-4.0.0' branch.
> >
> > It'd be great if we could sneak these in during the freeze so that I
> > won't have to possibly regenerate them again after the post-release
> > merge flood ;)
>
> Peter sent the same patch for x86_64 as well, there is one difference,
> you also have all the Xen things enabled which would be nice to not
> have it there since we don't care about it.
>
> I acked Peter's patch so can you please re-post again with
> --disable-xen appended to the configure of QEMU?
We might not care in RHEL, but we certainly *do* care upstream.
Not correct, sure we care about the Xen hypervisor and drivers but we
do not care about the Xen stuff in QEMU driver where we use replies.
More specifically, I built both QEMU and libvirt on Fedora 29 after
running 'dnf builddep' for the respective packages, so there should
be nothing enabled that would not be enabled in the Fedora packages:
in fact, I compared the replies and they're identical.
Yes, in fedora the Xen part is enabled because Xen uses QEMU to
emulate some aspects of the VM and Xen is supported there so the
dependencies to enable Xen support in QEMU are there by default.
Additionally, if you check out the existing replies you'll see
that
we had Xen support compiled into QEMU when we generated those for
versions 2.8, 2.9 and 2.10. And no, not all of those were provided
by me... You might actually be surprised when looking at the git
history for those files ;)
This is never a good argument :) if something was done in some way in
the past it doesn't mean that it's correct or preferred in present.
Pavel
8:22 a.m.
On Tue, 2019-04-30 at 15:02 +0200, Pavel Hrdina wrote:
On Tue, Apr 30, 2019 at 02:44:06PM +0200, Andrea Bolognani wrote:
> On Tue, 2019-04-30 at 13:55 +0200, Pavel Hrdina wrote:
> > Peter sent the same patch for x86_64 as well, there is one difference,
> > you also have all the Xen things enabled which would be nice to not
> > have it there since we don't care about it.
> >
> > I acked Peter's patch so can you please re-post again with
> > --disable-xen appended to the configure of QEMU?
>
> We might not care in RHEL, but we certainly *do* care upstream.
Not correct, sure we care about the Xen hypervisor and drivers but we
do not care about the Xen stuff in QEMU driver where we use replies.
> More specifically, I built both QEMU and libvirt on Fedora 29 after
> running 'dnf builddep' for the respective packages, so there should
> be nothing enabled that would not be enabled in the Fedora packages:
> in fact, I compared the replies and they're identical.
Yes, in fedora the Xen part is enabled because Xen uses QEMU to
emulate some aspects of the VM and Xen is supported there so the
dependencies to enable Xen support in QEMU are there by default.
Alright, the difference was partially lost on me. I now agree that
we don't need to have the Xen bits enabled in QEMU, and consequently
don't have any problem with Peter's patch being merged instead of
mine.
> Additionally, if you check out the existing replies you'll
see that
> we had Xen support compiled into QEMU when we generated those for
> versions 2.8, 2.9 and 2.10. And no, not all of those were provided
> by me... You might actually be surprised when looking at the git
> history for those files ;)
This is never a good argument :) if something was done in some way in
the past it doesn't mean that it's correct or preferred in present.
I completely agree, but in this case there's nothing problematic
with having Xen support built into QEMU when probing capabilities.
Realistically speaking, a significant number of libvirt developers
are on Fedora, so replies generated from a QEMU build that includes
Xen support is going to sneak in again eventually. And it will not
cause any harm.
Anyway, the rest of the replies were generated from QEMU binaries
built on RHEL, and on non-x86 architectures too, so we don't have to
worry about those accidentally containing Xen support :)
--
Andrea Bolognani / Red Hat / Virtualization
8:27 a.m.
On Tue, Apr 30, 2019 at 03:22:03PM +0200, Andrea Bolognani wrote:
On Tue, 2019-04-30 at 15:02 +0200, Pavel Hrdina wrote:
> On Tue, Apr 30, 2019 at 02:44:06PM +0200, Andrea Bolognani wrote:
> > On Tue, 2019-04-30 at 13:55 +0200, Pavel Hrdina wrote:
> > > Peter sent the same patch for x86_64 as well, there is one difference,
> > > you also have all the Xen things enabled which would be nice to not
> > > have it there since we don't care about it.
> > >
> > > I acked Peter's patch so can you please re-post again with
> > > --disable-xen appended to the configure of QEMU?
> >
> > We might not care in RHEL, but we certainly *do* care upstream.
>
> Not correct, sure we care about the Xen hypervisor and drivers but we
> do not care about the Xen stuff in QEMU driver where we use replies.
>
> > More specifically, I built both QEMU and libvirt on Fedora 29 after
> > running 'dnf builddep' for the respective packages, so there should
> > be nothing enabled that would not be enabled in the Fedora packages:
> > in fact, I compared the replies and they're identical.
>
> Yes, in fedora the Xen part is enabled because Xen uses QEMU to
> emulate some aspects of the VM and Xen is supported there so the
> dependencies to enable Xen support in QEMU are there by default.
Alright, the difference was partially lost on me. I now agree that
we don't need to have the Xen bits enabled in QEMU, and consequently
don't have any problem with Peter's patch being merged instead of
mine.
> > Additionally, if you check out the existing replies you'll see that
> > we had Xen support compiled into QEMU when we generated those for
> > versions 2.8, 2.9 and 2.10. And no, not all of those were provided
> > by me... You might actually be surprised when looking at the git
> > history for those files ;)
>
> This is never a good argument :) if something was done in some way in
> the past it doesn't mean that it's correct or preferred in present.
I completely agree, but in this case there's nothing problematic
with having Xen support built into QEMU when probing capabilities.
Realistically speaking, a significant number of libvirt developers
are on Fedora, so replies generated from a QEMU build that includes
Xen support is going to sneak in again eventually. And it will not
cause any harm.
Anyway, the rest of the replies were generated from QEMU binaries
built on RHEL, and on non-x86 architectures too, so we don't have to
worry about those accidentally containing Xen support :)
IMHO we should not generate standard replies from the QEMU binaries
from RHEL, unless we are specifically looking to cover the RHEL fork
of QEMU. RHEL cannot be consistently assumed to match upstream QEMU
behaviour due to RHEL's fairly aggressive patch backporting. The
Fedora builds are essentially vanilla upstream code, so a better bet
for generic capabilities.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
8:41 a.m.
On Tue, 2019-04-30 at 14:27 +0100, Daniel P. Berrangé wrote:
On Tue, Apr 30, 2019 at 03:22:03PM +0200, Andrea Bolognani wrote:
> Anyway, the rest of the replies were generated from QEMU binaries
> built on RHEL, and on non-x86 architectures too, so we don't have to
> worry about those accidentally containing Xen support :)
IMHO we should not generate standard replies from the QEMU binaries
from RHEL, unless we are specifically looking to cover the RHEL fork
of QEMU. RHEL cannot be consistently assumed to match upstream QEMU
behaviour due to RHEL's fairly aggressive patch backporting. The
Fedora builds are essentially vanilla upstream code, so a better bet
for generic capabilities.
I built upstream QEMU *on* RHEL, then generated replies from those
binaries. Whatever patching is done to QEMU in RHEL, it does not at
any point enter the picture.
I could conceivably provision the same machines with Fedora and build
QEMU + libvirt there, but that would be quite a bit of extra work on
top of something that's not fun nor quick to do in the first place,
so I'd rather keep using RHEL as the build OS. I'm also unconvinced
the result would be substantially different.
--
Andrea Bolognani / Red Hat / Virtualization
8:44 a.m.
On Tue, Apr 30, 2019 at 03:41:18PM +0200, Andrea Bolognani wrote:
On Tue, 2019-04-30 at 14:27 +0100, Daniel P. Berrangé wrote:
> On Tue, Apr 30, 2019 at 03:22:03PM +0200, Andrea Bolognani wrote:
> > Anyway, the rest of the replies were generated from QEMU binaries
> > built on RHEL, and on non-x86 architectures too, so we don't have to
> > worry about those accidentally containing Xen support :)
>
> IMHO we should not generate standard replies from the QEMU binaries
> from RHEL, unless we are specifically looking to cover the RHEL fork
> of QEMU. RHEL cannot be consistently assumed to match upstream QEMU
> behaviour due to RHEL's fairly aggressive patch backporting. The
> Fedora builds are essentially vanilla upstream code, so a better bet
> for generic capabilities.
I built upstream QEMU *on* RHEL, then generated replies from those
binaries. Whatever patching is done to QEMU in RHEL, it does not at
any point enter the picture.
I could conceivably provision the same machines with Fedora and build
QEMU + libvirt there, but that would be quite a bit of extra work on
top of something that's not fun nor quick to do in the first place,
so I'd rather keep using RHEL as the build OS. I'm also unconvinced
the result would be substantially different.
Ah, that's reasonably safe right now, as QMP is largely static. So
even if features are disabled at build time, most stuff still appears
in QMP. QMP is getting more dynamic though, so that it respects
build time choices better. Thus in future we should aim to ahve
a consistent (maximum) set of features enabled in QEMU builds.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
2026
days inactive
2033
days old
16 comments
4 participants
participants (4)
-
Andrea Bolognani -
Daniel P. Berrangé -
Pavel Hrdina -
Peter Krempa