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

[Pavel Hrdina]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180517/ddbfd09a/attachment-0001.sig>