[libvirt] [PATCH] tests: Update caps for QEMU 2.12.0 on s390x
Boris Fiuczynski
fiuczy at linux.ibm.com
Wed May 16 08:40:34 UTC 2018
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 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.
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 at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
--
Mit freundlichen Grüßen/Kind regards
Boris Fiuczynski
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
More information about the libvir-list
mailing list