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

[Boris Fiuczynski]

On 05/17/2018 10:19 AM, Pavel Hrdina wrote:
> On Thu, May 17, 2018 at 08:30:03AM +0200, Boris Fiuczynski wrote:
>> On 05/16/2018 06:30 PM, 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.
>>>
>>> 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.
>> Isn't the spice capability depending on how the qemu binary was build?
> 
> Yes, when running QEMU configure script you can disable/enable spice
> using --disable-spice or --enable-spice.  If you don't specify anything
> about spice the configure script will use pkg-config to figure out
> whether you have spice developer libs installed in your system or not.
> 
> Pavel
Since the required packages seem not to be available on s390x qemu on 
s390x is build without the support and the capability is not enabled.

> 
> 
> 
> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
> 


-- 
Mit freundlichen Grüßen/Kind regards
    Boris Fiuczynski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294