Re: [libvirt] [REPOST PATCH] tests: Update x86_64 replies, caps to QEMU 2.12

On 05/16/2018 11:09 AM, Pavel Hrdina wrote: > On Wed, May 16, 2018 at 10:52:56AM -0400, John Ferlan wrote: >> Using a QEMU 2.12 tagged tree build and full build, used: >> >> 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 >> >> Signed-off-by: John Ferlan <jferlan(a)redhat.com&gt; >> --- >> Reposting : >> >> https://www.redhat.com/archives/libvir-list/2018-May/msg00738.html >> >> with recent updates through commit id fe8a0679 > > I need to finish the work on adding some exact steps or possible docker > image to regenerate capabilities. But aren't some of the responses better tied to native hardware rather than virtualized (which I'm assuming a docker image may provide)? Especially the CPU ones and as seen from the s390x patch on list the response from qemuMonitorJSONGetKVMState. > > I would create a rule that if someone is updating replies files they > should check whether the CPU changes are only because of different host > CPU or whether there is some actual change. In the first case they > should not be part of the patch, it just pollutes the diff with > unnecessary changes. If we had/used the same, native box for each iteration of the capabilities files, then sure this probably would be easier unless someone (other than me ;-)) wants to mock a "fully featured" response. What we don't want to do is commit the emulated results, which I believe was done in the last go around - check the s390x results for the GetKVMState reply (libvirt-7) compared to what's posted upstream from real hardware yesterday by Shalini.