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

[John Ferlan]

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.

I also don't think it's "right" to edit whatever CPU response one gets
just because it's run on different hardware just so we can avoid
polluting the diff.  Again, back to my previous points - same, native
hardware or better mocking...

> 
> Additional note related to the first paragraph, I don't thing that we
> need to include "xen" related things in replies since they are not used
> by QEMU driver.
> 

I was wondering why those xen* things showed up - perhaps because my
environment included the xen-devel package... After removing, yep those
go away...  I could post another version, but it sounds like this isn't
desired anyway - so I won't pursue it too much.  Just figured it would
be better to have 2.12 instead of 2.11.90 in the caps/replies that we
store. The details of CPU differences seem to always be a given. We
don't "filter" the initial posting based on it so requiring any update
posted by someone using different hardware would seem to be overkill
especially since it doesn't really seem to matter.

John

BTW: It also seems spice* type flags/bits only show up in certain
environments - so that perhaps too could be considered for some sort of
mocking.  Something that's different between the s390x results posted
upstream as well as the x86_64 results I created.