[libvirt] [PATCH] tests: Update caps for QEMU 2.12.0 on s390x
Shalini Chellathurai Saroja
shalini at linux.vnet.ibm.com
Wed May 16 15:56:45 UTC 2018
On 05/16/2018 04:41 PM, John Ferlan wrote:
>
> 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...
Thank you :-).
>
> 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
>>>
>>
> --
> 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