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@xxxxxxxxxxxxxxxxxx>
---
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@xxxxxxxxxx>
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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
