Re: [PATCH libvirt v1] tests: add capabilities for QEMU 5.2.0 on s390x
On 1/12/21 11:09 AM, Andrea Bolognani wrote: On Tue, 2021-01-12 at 09:17 +0100, Shalini Chellathurai Saroja wrote: On 1/4/21 9:44 AM, Andrea Bolognani wrote: On Mon, 2020-12-28 at 12:41 +0100, Shalini Chellathurai Saroja wrote: On 12/17/20 12:19 PM, Andrea Bolognani wrote: On Wed, 2020-12-16 at 10:10 +0100, Shalini Chellathurai Saroja wrote: +++ b/tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml @@ -0,0 +1,3300 @@ + + /usr/bin/qemu-system-s390x + 5002000 + 0 + 39100243 + qemu-5.2.0-20201215.0.ba93e22c.fc32 ... the version string seems to indicate you're grabbing the replies from a packaged version rather than a build made from pristine upstream sources: this is consistent with what was done for earlier QEMU capabilities on s390x, but not with how we usually do things for other architectures - see the other caps_5.2.0.*.replies files. I don't think this is a blocker, because a Fedora-based package will be quite close to upstream anyway, but it would be great if you could generate the replies file again against a QEMU binary that's been built exclusively from upstream sources. You can then submit the update as a follow-up patch - I expect such patch to be fairly small. The replies are actually generated from the QEMU 5.2.0 binary built exclusively from upstream. This is also true for the other s390 replies generated for the earlier versions of QEMU. So how are you actually building the binary? Because if you just clone the upstream repository and run the usual ./configure && make inside it, the version number will not look like that... The presence of .fc32 specifically seems to indicate a .spec file is involved in some capacity. Hello Andrea, Happy New Year:-) We are using an automated build system which creates rpm packages from upstream QEMU 5.2.0. Yes, a .spec file is involved. I see. As long as you're using unadulterated upstream sources I don't think we have a problem here, and you shouldn't spend time changing your process. I agree, thank you:-) Thanks again! -- Kind regards Shalini Chellathurai Saroja Linux on Z and Virtualization Development Vorsitzende des Aufsichtsrats: Gregor Pillen Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
Re: [PATCH libvirt v1] tests: add capabilities for QEMU 5.2.0 on s390x
On Tue, 2021-01-12 at 09:17 +0100, Shalini Chellathurai Saroja wrote: > On 1/4/21 9:44 AM, Andrea Bolognani wrote: > > On Mon, 2020-12-28 at 12:41 +0100, Shalini Chellathurai Saroja wrote: > > > On 12/17/20 12:19 PM, Andrea Bolognani wrote: > > > > On Wed, 2020-12-16 at 10:10 +0100, Shalini Chellathurai Saroja wrote: > > > > > +++ b/tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml > > > > > @@ -0,0 +1,3300 @@ > > > > > + > > > > > + /usr/bin/qemu-system-s390x > > > > > + 5002000 > > > > > + 0 > > > > > + 39100243 > > > > > + qemu-5.2.0-20201215.0.ba93e22c.fc32 > > > > > > > > ... the version string seems to indicate you're grabbing the replies > > > > from a packaged version rather than a build made from pristine > > > > upstream sources: this is consistent with what was done for earlier > > > > QEMU capabilities on s390x, but not with how we usually do things for > > > > other architectures - see the other caps_5.2.0.*.replies files. > > > > > > > > I don't think this is a blocker, because a Fedora-based package will > > > > be quite close to upstream anyway, but it would be great if you could > > > > generate the replies file again against a QEMU binary that's been > > > > built exclusively from upstream sources. You can then submit the > > > > update as a follow-up patch - I expect such patch to be fairly small. > > > > > > The replies are actually generated from the QEMU 5.2.0 binary built > > > exclusively > > > from upstream. This is also true for the other s390 replies generated for > > > the earlier versions of QEMU. > > > > So how are you actually building the binary? Because if you just > > clone the upstream repository and run the usual ./configure && make > > inside it, the version number will not look like that... The presence > > of .fc32 specifically seems to indicate a .spec file is involved in > > some capacity. > > Hello Andrea, > > Happy New Year:-) > > We are using an automated build system which creates rpm packages from > upstream QEMU 5.2.0. > Yes, a .spec file is involved. I see. As long as you're using unadulterated upstream sources I don't think we have a problem here, and you shouldn't spend time changing your process. Thanks again! -- Andrea Bolognani / Red Hat / Virtualization
Re: [PATCH libvirt v1] tests: add capabilities for QEMU 5.2.0 on s390x
On 1/4/21 9:44 AM, Andrea Bolognani wrote: On Mon, 2020-12-28 at 12:41 +0100, Shalini Chellathurai Saroja wrote: On 12/17/20 12:19 PM, Andrea Bolognani wrote: On Wed, 2020-12-16 at 10:10 +0100, Shalini Chellathurai Saroja wrote: +++ b/tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml @@ -0,0 +1,3300 @@ + + /usr/bin/qemu-system-s390x + 5002000 + 0 + 39100243 + qemu-5.2.0-20201215.0.ba93e22c.fc32 ... the version string seems to indicate you're grabbing the replies from a packaged version rather than a build made from pristine upstream sources: this is consistent with what was done for earlier QEMU capabilities on s390x, but not with how we usually do things for other architectures - see the other caps_5.2.0.*.replies files. I don't think this is a blocker, because a Fedora-based package will be quite close to upstream anyway, but it would be great if you could generate the replies file again against a QEMU binary that's been built exclusively from upstream sources. You can then submit the update as a follow-up patch - I expect such patch to be fairly small. The replies are actually generated from the QEMU 5.2.0 binary built exclusively from upstream. This is also true for the other s390 replies generated for the earlier versions of QEMU. So how are you actually building the binary? Because if you just clone the upstream repository and run the usual ./configure && make inside it, the version number will not look like that... The presence of .fc32 specifically seems to indicate a .spec file is involved in some capacity. Hello Andrea, Happy New Year:-) We are using an automated build system which creates rpm packages from upstream QEMU 5.2.0. Yes, a .spec file is involved. Thank you Shalini C S -- Kind regards Shalini Chellathurai Saroja Linux on Z and Virtualization Development Vorsitzende des Aufsichtsrats: Gregor Pillen Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
Re: [PATCH libvirt v1] tests: add capabilities for QEMU 5.2.0 on s390x
On Mon, 2020-12-28 at 12:41 +0100, Shalini Chellathurai Saroja wrote: > On 12/17/20 12:19 PM, Andrea Bolognani wrote: > > On Wed, 2020-12-16 at 10:10 +0100, Shalini Chellathurai Saroja wrote: > > > +++ b/tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml > > > @@ -0,0 +1,3300 @@ > > > + > > > + /usr/bin/qemu-system-s390x > > > + 5002000 > > > + 0 > > > + 39100243 > > > + qemu-5.2.0-20201215.0.ba93e22c.fc32 > > > > ... the version string seems to indicate you're grabbing the replies > > from a packaged version rather than a build made from pristine > > upstream sources: this is consistent with what was done for earlier > > QEMU capabilities on s390x, but not with how we usually do things for > > other architectures - see the other caps_5.2.0.*.replies files. > > > > I don't think this is a blocker, because a Fedora-based package will > > be quite close to upstream anyway, but it would be great if you could > > generate the replies file again against a QEMU binary that's been > > built exclusively from upstream sources. You can then submit the > > update as a follow-up patch - I expect such patch to be fairly small. > > The replies are actually generated from the QEMU 5.2.0 binary built > exclusively > from upstream. This is also true for the other s390 replies generated for > the earlier versions of QEMU. So how are you actually building the binary? Because if you just clone the upstream repository and run the usual ./configure && make inside it, the version number will not look like that... The presence of .fc32 specifically seems to indicate a .spec file is involved in some capacity. -- Andrea Bolognani / Red Hat / Virtualization
Re: [PATCH libvirt v1] tests: add capabilities for QEMU 5.2.0 on s390x
On 12/17/20 12:19 PM, Andrea Bolognani wrote: On Wed, 2020-12-16 at 10:10 +0100, Shalini Chellathurai Saroja wrote: tests/domaincapsdata/qemu_5.2.0.s390x.xml | 231 + .../caps_5.2.0.s390x.replies | 25458 .../qemucapabilitiesdata/caps_5.2.0.s390x.xml | 3300 ++ ...default-video-type-s390x.s390x-latest.args | 9 +- .../disk-error-policy-s390x.s390x-latest.args |16 +- .../fs9p-ccw.s390x-latest.args| 8 +- ...tdev-subsys-mdev-vfio-ap.s390x-latest.args | 4 +- ...ubsys-mdev-vfio-ccw-boot.s390x-latest.args | 4 +- ...othreads-virtio-scsi-ccw.s390x-latest.args | 6 +- ...t-cpu-kvm-ccw-virtio-2.7.s390x-latest.args | 4 +- ...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 9 +- ...t-cpu-tcg-ccw-virtio-2.7.s390x-latest.args | 4 +- ...t-cpu-tcg-ccw-virtio-4.2.s390x-latest.args | 4 +- .../s390x-ccw-graphics.s390x-latest.args | 8 +- .../s390x-ccw-headless.s390x-latest.args | 8 +- .../vhost-vsock-ccw-auto.s390x-latest.args| 8 +- .../vhost-vsock-ccw.s390x-latest.args | 8 +- 17 files changed, 29054 insertions(+), 35 deletions(-) create mode 100644 tests/domaincapsdata/qemu_5.2.0.s390x.xml create mode 100644 tests/qemucapabilitiesdata/caps_5.2.0.s390x.replies create mode 100644 tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml The diff looks sane enough, so Reviewed-by: Andrea Bolognani and pushed. Thanks for helping! Hello Andrea, Thank you for the review:-) Sure, you are welcome:-) However... +++ b/tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml @@ -0,0 +1,3300 @@ + + /usr/bin/qemu-system-s390x + 5002000 + 0 + 39100243 + qemu-5.2.0-20201215.0.ba93e22c.fc32 ... the version string seems to indicate you're grabbing the replies from a packaged version rather than a build made from pristine upstream sources: this is consistent with what was done for earlier QEMU capabilities on s390x, but not with how we usually do things for other architectures - see the other caps_5.2.0.*.replies files. I don't think this is a blocker, because a Fedora-based package will be quite close to upstream anyway, but it would be great if you could generate the replies file again against a QEMU binary that's been built exclusively from upstream sources. You can then submit the update as a follow-up patch - I expect such patch to be fairly small. The replies are actually generated from the QEMU 5.2.0 binary built exclusively from upstream. This is also true for the other s390 replies generated for the earlier versions of QEMU. I can modify the package name from qemu-5.2.0-20201215.0.ba93e22c.fc32 to qemu-5.2.0, to make it more obvious that it is an upstream version and not a distro package. Would it be ok? Thanks again for your help getting updated capabilities in libvirt :) You are welcome:-) -- Kind regards Shalini Chellathurai Saroja Linux on Z and Virtualization Development Vorsitzende des Aufsichtsrats: Gregor Pillen Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
Re: [PATCH libvirt v1] tests: add capabilities for QEMU 5.2.0 on s390x
On Wed, 2020-12-16 at 10:10 +0100, Shalini Chellathurai Saroja wrote: > tests/domaincapsdata/qemu_5.2.0.s390x.xml | 231 + > .../caps_5.2.0.s390x.replies | 25458 > .../qemucapabilitiesdata/caps_5.2.0.s390x.xml | 3300 ++ > ...default-video-type-s390x.s390x-latest.args | 9 +- > .../disk-error-policy-s390x.s390x-latest.args |16 +- > .../fs9p-ccw.s390x-latest.args| 8 +- > ...tdev-subsys-mdev-vfio-ap.s390x-latest.args | 4 +- > ...ubsys-mdev-vfio-ccw-boot.s390x-latest.args | 4 +- > ...othreads-virtio-scsi-ccw.s390x-latest.args | 6 +- > ...t-cpu-kvm-ccw-virtio-2.7.s390x-latest.args | 4 +- > ...t-cpu-kvm-ccw-virtio-4.2.s390x-latest.args | 9 +- > ...t-cpu-tcg-ccw-virtio-2.7.s390x-latest.args | 4 +- > ...t-cpu-tcg-ccw-virtio-4.2.s390x-latest.args | 4 +- > .../s390x-ccw-graphics.s390x-latest.args | 8 +- > .../s390x-ccw-headless.s390x-latest.args | 8 +- > .../vhost-vsock-ccw-auto.s390x-latest.args| 8 +- > .../vhost-vsock-ccw.s390x-latest.args | 8 +- > 17 files changed, 29054 insertions(+), 35 deletions(-) > create mode 100644 tests/domaincapsdata/qemu_5.2.0.s390x.xml > create mode 100644 tests/qemucapabilitiesdata/caps_5.2.0.s390x.replies > create mode 100644 tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml The diff looks sane enough, so Reviewed-by: Andrea Bolognani and pushed. Thanks for helping! However... > +++ b/tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml > @@ -0,0 +1,3300 @@ > + > + /usr/bin/qemu-system-s390x > + 5002000 > + 0 > + 39100243 > + qemu-5.2.0-20201215.0.ba93e22c.fc32 ... the version string seems to indicate you're grabbing the replies from a packaged version rather than a build made from pristine upstream sources: this is consistent with what was done for earlier QEMU capabilities on s390x, but not with how we usually do things for other architectures - see the other caps_5.2.0.*.replies files. I don't think this is a blocker, because a Fedora-based package will be quite close to upstream anyway, but it would be great if you could generate the replies file again against a QEMU binary that's been built exclusively from upstream sources. You can then submit the update as a follow-up patch - I expect such patch to be fairly small. Thanks again for your help getting updated capabilities in libvirt :) -- Andrea Bolognani / Red Hat / Virtualization
