On Fri, 2019-05-03 at 10:46 +0200, Boris Fiuczynski wrote:
In addition adjusting *s390x-latest.args files to qemu deprecation
changes made
in commit e8c2c8bd078 (Prefer '-overcommit mem-lock' over -realtime mlock').
Signed-off-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com>
---
.../caps_3.1.0.s390x.replies | 20893 ++++++++++++++++
.../qemucapabilitiesdata/caps_3.1.0.s390x.xml | 2728 ++
...othreads-virtio-scsi-ccw.s390x-latest.args | 2 +-
.../s390x-ccw-graphics.s390x-latest.args | 2 +-
.../s390x-ccw-headless.s390x-latest.args | 2 +-
.../vhost-vsock-ccw-auto.s390x-latest.args | 2 +-
.../vhost-vsock-ccw.s390x-latest.args | 2 +-
7 files changed, 23626 insertions(+), 5 deletions(-)
create mode 100644 tests/qemucapabilitiesdata/caps_3.1.0.s390x.replies
create mode 100644 tests/qemucapabilitiesdata/caps_3.1.0.s390x.xml
A few things.
First of all, while this message reached my inbox just fine, it
didn't reach the list yet because of the sheer size, which is way
over the configured limit and thus got stuck in the moderation,
needing manual intervention to get through. In the future, please
consider sending a snipped version to the mailing list and making
the full changes available somewhere, like I've done for example
with
https://www.redhat.com/archives/libvir-list/2019-April/msg01490.html
You also mention adjusting some .args files: I hope you haven't
done so manually, but rather executed
VIR_TEST_REGENERATE_OUTPUT=1 make check
and let it fix the output files for you. If not, TYL ;)
As for the patch itself: while it looks fine, personally I don't
feel we need to have capabilities for every single QEMU version on
every single architecture, so considering that you're adding 4.0.0
in the same series and there aren't any 3.1.0-specific tests, I
would say let's just skip this one version and add capabilitie for
4.0.0 only. Does that sound reasonable?
--
Andrea Bolognani / Red Hat / Virtualization