On 05/16/2018 04:40 AM, Boris Fiuczynski wrote:
On 05/15/2018 10:37 PM, John Ferlan wrote:
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@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.
Shalini used the process you outlined above on a z14. She also used a 2.12 GA qemu build on s390. My expectation of the qemucapabilitiestest has been so far that these tests are trying to be a reality check against an architecture which obviously should use replies files generated on real hardware of the architecture.
I'll add the following to the commit message: Used a z14 using a QEMU 2.12 GA build and the following sequence: tests/qemucapsprobe /path/to/s390x-softmmu/qemu-system-s390x > \ tests/qemucapabilitiesdata/caps_2.12.0.s390x.replies VIR_TEST_REGENERATE_OUTPUT=1 tests/qemucapabilitiestest VIR_TEST_REGENERATE_OUTPUT=1 tests/domaincapstest I also checked the 2.11 set that Shalini produced (commit id ab9e2041c) and saw that package was empty there as well (should have thought of that yesterday ;-)) So consider this Reviewed-by: John Ferlan <jferlan@redhat.com> and I've merged in the adjustment from yesterday for "<flag name='sdl-gl'/>" I will push the changes later... Tks - John
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.
We have not produced the previous set of 2.12. Andrea Bolognani did create them and I agree that it must have been on an emulated environment.
+ <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"
See two below.
}, "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... Correct.
"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
Looking in the replies file it is empty and it also has been empty in the past. Running qemu-system-s390x --version QEMU emulator version 2.12.0 Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
<arch>s390x</arch>
[...]
John
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list