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

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.

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 -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list