[libvirt] [PATCH] tests: Update caps for QEMU 2.12.0 on s390x
John Ferlan
jferlan at redhat.com
Tue May 15 20:37:13 UTC 2018
On 05/15/2018 07:46 AM, Shalini Chellathurai Saroja wrote:
> Let us update the existing xml and replies files for QEMU 2.12.0 on
> s390x.
>
> Signed-off-by: Shalini Chellathurai Saroja <shalini at linux.vnet.ibm.com>
> ---
> tests/domaincapsschemadata/qemu_2.12.0.s390x.xml | 99 +-
> .../qemucapabilitiesdata/caps_2.12.0.s390x.replies | 5001 +++++++++++---------
> tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml | 113 +-
> 3 files changed, 2974 insertions(+), 2239 deletions(-)
>
Curious about your process for creating the files due to the differences
seen. I assume you use real hardware...
For x86_64, I will build a QEMU using the v2.12 tag, then in my libvirt
tree run:
tests/qemucapsprobe /home/qemu/x86_64-softmmu/qemu-system-x86_64 > \
tests/qemucapabilitiesdata/caps_2.12.0.x86_64.replies
VIR_TEST_REGENERATE_OUTPUT=1 tests/qemucapabilitiestest
VIR_TEST_REGENERATE_OUTPUT=1 tests/domaincapstest
My purpose for asking is to know if real hardware was used and then to
be able to have a "history" of how the previous version built the files
so that the next time someone comes along they can use the same process.
If I run the same sequence above on my x86_64 box, but use the s390x
emulator - I get different results - not unexpected for some things...
One difference that causes me to wonder is I have spice flag being set,
but this reply doesn't. It's strange and I'm not quite sure what's
happening at this point!
> diff --git a/tests/domaincapsschemadata/qemu_2.12.0.s390x.xml b/tests/domaincapsschemadata/qemu_2.12.0.s390x.xml
> index 4bacb879fe..1475451e68 100644
> --- a/tests/domaincapsschemadata/qemu_2.12.0.s390x.xml
> +++ b/tests/domaincapsschemadata/qemu_2.12.0.s390x.xml
> @@ -22,8 +22,103 @@
> </os>
> <cpu>
> <mode name='host-passthrough' supported='yes'/>
> - <mode name='host-model' supported='no'/>
> - <mode name='custom' supported='no'/>
Based on these, I have a feeling the current files may have been built
in an emulated environment, but that's just my gut feel. Nothing
necessarily wrong with what you did.
> + <mode name='host-model' supported='yes'>
> + <model fallback='forbid'>z14-base</model>
> + <feature policy='require' name='aen'/>
> + <feature policy='require' name='aefsi'/>
> + <feature policy='require' name='msa8'/>
> + <feature policy='require' name='msa7'/>
> + <feature policy='require' name='msa6'/>
> + <feature policy='require' name='msa5'/>
> + <feature policy='require' name='msa4'/>
> + <feature policy='require' name='msa3'/>
> + <feature policy='require' name='msa2'/>
> + <feature policy='require' name='msa1'/>
> + <feature policy='require' name='sthyi'/>
> + <feature policy='require' name='edat'/>
> + <feature policy='require' name='ri'/>
> + <feature policy='require' name='edat2'/>
> + <feature policy='require' name='vx'/>
> + <feature policy='require' name='ipter'/>
> + <feature policy='require' name='vxeh'/>
> + <feature policy='require' name='vxpd'/>
> + <feature policy='require' name='esop'/>
> + <feature policy='require' name='iep'/>
> + <feature policy='require' name='cte'/>
> + <feature policy='require' name='gs'/>
> + <feature policy='require' name='ppa15'/>
> + <feature policy='require' name='zpci'/>
> + <feature policy='require' name='sea_esop2'/>
> + <feature policy='require' name='te'/>
> + <feature policy='require' name='cmm'/>
> + </mode>
> + <mode name='custom' supported='yes'>
> + <model usable='yes'>z890.2</model>
> + <model usable='yes'>z990.4</model>
> + <model usable='yes'>z10BC.2</model>
> + <model usable='yes'>z196.2</model>
> + <model usable='yes'>z14</model>
> + <model usable='yes'>z9BC-base</model>
> + <model usable='yes'>zEC12-base</model>
> + <model usable='yes'>z196-base</model>
> + <model usable='yes'>z13-base</model>
> + <model usable='yes'>z990.3</model>
> + <model usable='yes'>z9EC</model>
> + <model usable='yes'>zBC12</model>
> + <model usable='yes'>z9EC.3</model>
> + <model usable='yes'>z196.2-base</model>
> + <model usable='no'>qemu</model>
> + <model usable='yes'>zEC12.2-base</model>
> + <model usable='yes'>z800-base</model>
> + <model usable='yes'>z9EC.2</model>
> + <model usable='yes'>z900.2-base</model>
> + <model usable='yes'>z900.3</model>
> + <model usable='yes'>z890-base</model>
> + <model usable='yes'>z890</model>
> + <model usable='yes'>z990.4-base</model>
> + <model usable='yes'>z10BC.2-base</model>
> + <model usable='yes'>z900.2</model>
> + <model usable='yes'>z9BC.2-base</model>
> + <model usable='yes'>z800</model>
> + <model usable='yes'>z114</model>
> + <model usable='yes'>z13</model>
> + <model usable='yes'>z13s-base</model>
> + <model usable='yes'>z990</model>
> + <model usable='yes'>z990.2</model>
> + <model usable='yes'>z14-base</model>
> + <model usable='yes'>z890.2-base</model>
> + <model usable='yes'>z196</model>
> + <model usable='yes'>z10EC</model>
> + <model usable='yes'>z13s</model>
> + <model usable='yes'>z900</model>
> + <model usable='yes'>z10EC.3</model>
> + <model usable='yes'>z10EC.2-base</model>
> + <model usable='yes'>z114-base</model>
> + <model usable='yes'>z990.2-base</model>
> + <model usable='yes'>z9EC.2-base</model>
> + <model usable='yes'>z890.3</model>
> + <model usable='yes'>z900.3-base</model>
> + <model usable='yes'>z9BC.2</model>
> + <model usable='yes'>z10BC</model>
> + <model usable='yes'>z990.5</model>
> + <model usable='yes'>zEC12.2</model>
> + <model usable='yes'>z10EC-base</model>
> + <model usable='yes'>z9EC-base</model>
> + <model usable='yes'>z9EC.3-base</model>
> + <model usable='yes'>zEC12</model>
> + <model usable='yes'>z990.5-base</model>
> + <model usable='yes'>z10BC-base</model>
> + <model usable='yes'>z900-base</model>
> + <model usable='yes'>z13.2</model>
> + <model usable='yes'>z890.3-base</model>
> + <model usable='yes'>zBC12-base</model>
> + <model usable='yes'>z13.2-base</model>
> + <model usable='yes'>z990-base</model>
> + <model usable='yes'>z10EC.2</model>
> + <model usable='yes'>z9BC</model>
> + <model usable='yes'>z10EC.3-base</model>
> + <model usable='yes'>z990.3-base</model>
> + </mode>
> </cpu>
> <devices>
> <disk supported='yes'>
> diff --git a/tests/qemucapabilitiesdata/caps_2.12.0.s390x.replies b/tests/qemucapabilitiesdata/caps_2.12.0.s390x.replies
> index a93e5984c6..29c3403550 100644
> --- a/tests/qemucapabilitiesdata/caps_2.12.0.s390x.replies
> +++ b/tests/qemucapabilitiesdata/caps_2.12.0.s390x.replies
> @@ -2,14 +2,13 @@
> "QMP": {
> "version": {
> "qemu": {
> - "micro": 90,
> - "minor": 11,
> + "micro": 0,
> + "minor": 12,
> "major": 2
> },
> - "package": "v2.12.0-rc0"
> + "package": ""
This in particular concerns me as, I think it should be :
"package": "v2.12.0"
> },
> "capabilities": [
> - "oob"
> ]
> }
> }
> @@ -23,11 +22,11 @@
> {
> "return": {
> "qemu": {
> - "micro": 90,
> - "minor": 11,
> + "micro": 0,
> + "minor": 12,
> "major": 2
> },
> - "package": "v2.12.0-rc0"
> + "package": ""
Likewise...
> },
> "id": "libvirt-2"
> }
> @@ -530,7 +529,7 @@
>
> {
> "return": {
> - "fd": 17,
> + "fd": 18,
> "fdset-id": 0
> },
> "id": "libvirt-5"
> @@ -546,7 +545,7 @@
>
> {
> "return": {
> - "enabled": false,
> + "enabled": true,
> "present": true
> },
BTW: This is why I think you used real hardware and the previous one was
built using just the emulator. I believe this is the response from the
qemuMonitorJSONGetKVMState call in virQEMUCapsProbeQMPKVMState.
Which if I'm reading things correctly perhaps explains differences later
on here for unavailable cpu features in the existing replies file [I've
cut that out of this reply, but can be seen in the original diff...
> "id": "libvirt-7"
> @@ -1241,10 +1240,6 @@
> "name": "fw_cfg_io",
> "parent": "fw_cfg"
> },
[...]
> diff --git a/tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml b/tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml
> index 607274ebb7..c486340c7d 100644
> --- a/tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml
> +++ b/tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml
> @@ -3,7 +3,7 @@
> <selfctime>0</selfctime>
> <selfvers>0</selfvers>
> <usedQMP/>
> - <flag name='enable-kvm'/>
> + <flag name='kvm'/>
> <flag name='boot-index'/>
> <flag name='virtio-tx-alg'/>
> <flag name='virtio-blk-pci.ioeventfd'/>
> @@ -126,11 +126,108 @@
> <flag name='virtual-css-bridge'/>
> <flag name='virtual-css-bridge.cssid-unrestricted'/>
> <flag name='vfio-ccw'/>
> - <version>2011090</version>
> + <version>2012000</version>
> <kvmVersion>0</kvmVersion>
> - <microcodeVersion>0</microcodeVersion>
> - <package>v2.12.0-rc0</package>
> + <microcodeVersion>371055</microcodeVersion>
> + <package></package>
This would be filled in from the replies, but I don't believe it should
be empty
> <arch>s390x</arch>
[...]
John
More information about the libvir-list
mailing list