[libvirt PATCH 0/3] tests: Add capabilities for QEMU 5.2

[Andrea Bolognani]

On Thu, 2020-12-10 at 16:07 +0100, Andrea Bolognani wrote:
> As usual, this is an abridged version of the changes.
> 
> For the full version, run
> 
>   $ git fetch https://gitlab.com/abologna/libvirt.git caps-5.2
> 
> or browse
> 
>   https://gitlab.com/abologna/libvirt/-/commits/caps-5.2
> 
> Andrea Bolognani (3):
>   tests: Add capabilities for QEMU 5.2 on aarch64
>   tests: Add capabilities for QEMU 5.2 on ppc64
>   tests: Add capabilities for QEMU 5.2 on riscv64

Thomas and Cornelia,

you might notice there's an architecture missing from this list O:-)

Any chance either of you can generate the .replies file on s390x? I
have tried doing so myself, but ran into several issues; after
working around them one by one, I eventually realized that the
machine I was using is not KVM-capable and thus the resulting file
would be close to useless. The idea of locating an s390x machine that
doesn't suffer from that limitation and repeating the entire process
from scratch is obviously not sounding very appealing right now!

Assuming you have access to KVM-capable hardware that is running a
recent OS, the process of generating these files is relatively
straightforward:

  * build QEMU from git (v5.2.0 tag)

  * build libvirt from git (master branch)

  * from inside libvirt's build directory, run

      $ ./tests/qemucapsprobe \
        ~/path/to/your/qemu-system-s390x \
        >../tests/qemucapabilitiesdata/caps_5.2.0.s390x.replies

  * after the .replies file has been generated, it's just a matter
    of running

      $ VIR_TEST_REGENERATE_OUTPUT=1 meson test

    a few times, let's say 3-5, until it passes. If it still fails
    after 5 iterations, then there's some issue that we need to
    look into, but I don't expect that will be the case

I'd really appreciate if either one of you could go through this
process and post the resulting patch! Note that, since the diff is
going to be massive, it's standard practice for this kind of update
to only send a heavily snipped version to the mailing list, and push
the full version to some publicly-accessible repository.

Thanks in advance :)

-- 
Andrea Bolognani / Red Hat / Virtualization