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

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(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. >> >> 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

-- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list