[libvirt] [PATCH 0/5] tests: Refresh/add capabilities for QEMU 4.0.0
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
Signed-off-by: Andrea Bolognani <abologna@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
Signed-off-by: Andrea Bolognani <abologna@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
On Mon, Apr 29, 2019 at 18:25:52 +0200, Andrea Bolognani wrote:
Signed-off-by: Andrea Bolognani <abologna@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
Signed-off-by: Andrea Bolognani <abologna@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
On Mon, Apr 29, 2019 at 18:25:53 +0200, Andrea Bolognani wrote:
Signed-off-by: Andrea Bolognani <abologna@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
Signed-off-by: Andrea Bolognani <abologna@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
On Mon, Apr 29, 2019 at 18:25:54 +0200, Andrea Bolognani wrote:
Signed-off-by: Andrea Bolognani <abologna@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
Signed-off-by: Andrea Bolognani <abologna@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
On Mon, Apr 29, 2019 at 18:25:55 +0200, Andrea Bolognani wrote:
Signed-off-by: Andrea Bolognani <abologna@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
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
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
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
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
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 :|
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
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 :|
participants (4)
-
Andrea Bolognani -
Daniel P. Berrangé -
Pavel Hrdina -
Peter Krempa