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

John Ferlan jferlan at redhat.com
Wed May 16 14:41:55 UTC 2018



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

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 at 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 at redhat.com
>> https://www.redhat.com/mailman/listinfo/libvir-list
>>
> 
> 




More information about the libvir-list mailing list