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

[Erik Skultety]

On Wed, May 16, 2018 at 12:30:30PM -0400, John Ferlan wrote:
>
>
> 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 at redhat.com>
> >> ---
> >>  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.

Actually, I spoke to Andrea earlier last week and he told me that he'd
generated these on a real HW using our machine reservation system, so the issue
you're describing might not be originating from an emulated environment rather
than missing some compilation options when he was building QEMU from source...
However, it's important that we've merged the update.

Erik