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

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.

> > 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 >