Re: [libvirt] [PATCH] tests: Update caps for QEMU 2.12.0 on s390x

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(a)linux.vnet.ibm.com&gt; >>> --- >>>   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(a)redhat.com&gt; 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(a)redhat.com >> https://www.redhat.com/mailman/listinfo/libvir-list >> > -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list