.../caps_4.2.0.aarch64.replies | 20684 +++++++++++++ .../caps_4.2.0.aarch64.xml | 321 + .../caps_4.2.0.ppc64.replies | 24406 ++++++++++++++++ .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1087 + 4 files changed, 46498 insertions(+) create mode 100644 tests/qemucapabilitiesdata/caps_4.2.0.aarch64.replies create mode 100644 tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml create mode 100644 tests/qemucapabilitiesdata/caps_4.2.0.ppc64.replies create mode 100644 tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml
This will be useful to test Jirka's changes to how we handle default CPU models on more architectures. The version posted to the list is heavily snipped, but you can grab the full one with $ git fetch https://gitlab.com/abologna/libvirt caps-4.2.0 Andrea Bolognani (2): tests: Add capabilitie for QEMU 4.2.0 on ppc64 tests: Add capabilitie for QEMU 4.2.0 on aarch64 .../caps_4.2.0.aarch64.replies | 20684 +++++++++++++ .../caps_4.2.0.aarch64.xml | 321 + .../caps_4.2.0.ppc64.replies | 24406 ++++++++++++++++ .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1087 + 4 files changed, 46498 insertions(+) create mode 100644 tests/qemucapabilitiesdata/caps_4.2.0.aarch64.replies create mode 100644 tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml create mode 100644 tests/qemucapabilitiesdata/caps_4.2.0.ppc64.replies create mode 100644 tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml -- 2.21.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Thu, Oct 10, 2019 at 16:56:29 +0200, Andrea Bolognani wrote: > This will be useful to test Jirka's changes to how we handle default > CPU models on more architectures. > > The version posted to the list is heavily snipped, but you can grab > the full one with > > $ git fetch https://gitlab.com/abologna/libvirt caps-4.2.0 > > Andrea Bolognani (2): > tests: Add capabilitie for QEMU 4.2.0 on ppc64 > tests: Add capabilitie for QEMU 4.2.0 on aarch64 > > .../caps_4.2.0.aarch64.replies | 20684 +++++++++++++ > .../caps_4.2.0.aarch64.xml | 321 + > .../caps_4.2.0.ppc64.replies | 24406 ++++++++++++++++ > .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1087 + > 4 files changed, 46498 insertions(+) > create mode 100644 tests/qemucapabilitiesdata/caps_4.2.0.aarch64.replies > create mode 100644 tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml > create mode 100644 tests/qemucapabilitiesdata/caps_4.2.0.ppc64.replies > create mode 100644 tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml Could you also add corresponding test cases to domaincapstest.c? Reviewed-by: Jiri Denemark <jdenemar@redhat.com> -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, 2019-10-11 at 08:51 +0200, Jiri Denemark wrote: > On Thu, Oct 10, 2019 at 16:56:29 +0200, Andrea Bolognani wrote: > > This will be useful to test Jirka's changes to how we handle default > > CPU models on more architectures. > > > > The version posted to the list is heavily snipped, but you can grab > > the full one with > > > > $ git fetch https://gitlab.com/abologna/libvirt caps-4.2.0 > > > > Andrea Bolognani (2): > > tests: Add capabilitie for QEMU 4.2.0 on ppc64 > > tests: Add capabilitie for QEMU 4.2.0 on aarch64 > > > > .../caps_4.2.0.aarch64.replies | 20684 +++++++++++++ > > .../caps_4.2.0.aarch64.xml | 321 + > > .../caps_4.2.0.ppc64.replies | 24406 ++++++++++++++++ > > .../qemucapabilitiesdata/caps_4.2.0.ppc64.xml | 1087 + > > 4 files changed, 46498 insertions(+) > > create mode 100644 tests/qemucapabilitiesdata/caps_4.2.0.aarch64.replies > > create mode 100644 tests/qemucapabilitiesdata/caps_4.2.0.aarch64.xml > > create mode 100644 tests/qemucapabilitiesdata/caps_4.2.0.ppc64.replies > > create mode 100644 tests/qemucapabilitiesdata/caps_4.2.0.ppc64.xml > > Could you also add corresponding test cases to domaincapstest.c? Sure, I'll squash that in. Is there any chance we can convert that test case to automatically pick up new .replies files, same as qemucapabilitiestest and qemucaps2xmltest? It's so much more convenient, and reduces the chance of missing the necessary changes to zero :) -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Andrea Bolognani <abologna@redhat.com> [2019-10-10, 04:56PM +0200]: > This will be useful to test Jirka's changes to how we handle default > CPU models on more architectures. > > The version posted to the list is heavily snipped, but you can grab > the full one with > > $ git fetch https://gitlab.com/abologna/libvirt caps-4.2.0 > > Andrea Bolognani (2): > tests: Add capabilitie for QEMU 4.2.0 on ppc64 > tests: Add capabilitie for QEMU 4.2.0 on aarch64 Although it actually is a pre-4.2.0 version for QEMU, right? I am confused, because for s390x we once where told that we do _NOT_ want pre-versions in the capability files? How do we handle those now? At least, please update the commit messages to reflect the actual changes. -- IBM Systems Linux on Z & Virtualization Development -------------------------------------------------- IBM Deutschland Research & Development GmbH Schönaicher Str. 220, 71032 Böblingen Phone: +49 7031 16 1819 -------------------------------------------------- Vorsitzende des Aufsichtsrats: Matthias Hartmann Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, 2019-10-11 at 10:59 +0200, Bjoern Walk wrote: > Andrea Bolognani <abologna@redhat.com> [2019-10-10, 04:56PM +0200]: > > This will be useful to test Jirka's changes to how we handle default > > CPU models on more architectures. > > > > The version posted to the list is heavily snipped, but you can grab > > the full one with > > > > $ git fetch https://gitlab.com/abologna/libvirt caps-4.2.0 > > > > Andrea Bolognani (2): > > tests: Add capabilitie for QEMU 4.2.0 on ppc64 > > tests: Add capabilitie for QEMU 4.2.0 on aarch64 > > Although it actually is a pre-4.2.0 version for QEMU, right? I am > confused, because for s390x we once where told that we do _NOT_ want > pre-versions in the capability files? How do we handle those now? We routinely introduce capabilities for pre-release versions of QEMU, because we want to implement support for new QEMU features as soon as possible rather than waiting for the corresponding QEMU release to be out. Of course doing so causes churn, because we then have to go back after the QEMU release has happened and update those capabilities to reflect the actual release, but the benefits outweight the drawbacks so we're okay with it. What we usually avoid is adding capabilities "just because": if adding the pre-release capabilities doesn't allow us to cover more useful scenarios in the test suite, then it makes sense to avoid the churn and introduce the capabilities after the QEMU release is out. In this specific case, as I mention above Jirka is working on a series that will exercise a QEMU 4.2.0-only feature, and having the capabilities for more architectures available will allow him to write tests that ensure the feature doesn't only work on x86; it just so happens that it's more convenient for me to generate these files than it is for him, so that's why these patches are their own series and not part of his upcoming one. > At least, please update the commit messages to reflect the actual > changes. I'm not sure I understand what you're suggesting I should change. Either way, the patches have already been pushed, but if you expand on your concerns I'll certainly keep them in mind next time. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2024 Red Hat, Inc.