| Message ID | 20201104115706.3101190-1-philmd@redhat.com |
|---|---|
| Headers | show |
| Series | ci: Move --without-default-devices job from Travis to GitLab | expand |
On 11/4/20 9:57 AM, Philippe Mathieu-Daudé wrote: > We test './configure --without-default-devices' since commit > 20885b5b169 (".travis.yml: test that no-default-device builds > do not regress") in Travis-CI. > > Since having a single CI to look at is easier, and GitLab-CI > is the preferred one, add the equivalent job there. > > As smoke test, run the qtests on the AVR target. Since the > boards are simple SoC, there is not issue with unavailable > default devices there. > Also include the m68k target which works fine. > > Reviewed-by: Thomas Huth <thuth@redhat.com> > Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> > --- > .gitlab-ci.yml | 7 +++++++ > 1 file changed, 7 insertions(+) Looks good to me. Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> > > diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml > index 3b15ae5c302..e4eba96ff34 100644 > --- a/.gitlab-ci.yml > +++ b/.gitlab-ci.yml > @@ -262,6 +262,13 @@ build-user-plugins: > MAKE_CHECK_ARGS: check-tcg > timeout: 1h 30m > > +build-system-ubuntu-without-default-devices: > + <<: *native_build_job_definition > + variables: > + IMAGE: ubuntu2004 > + CONFIGURE_ARGS: --without-default-devices --disable-user --disable-tools --disable-docs > + MAKE_CHECK_ARGS: check-qtest-avr check-qtest-m68k > + > build-clang: > <<: *native_build_job_definition > variables:
On Wed, 4 Nov 2020 12:57:03 +0100 Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > From: Cornelia Huck <cohuck@redhat.com> > > s390-pci-vfio.c calls into the vfio code, so we need it to be > built conditionally on vfio (which implies CONFIG_LINUX). > > Reported-by: Philippe Mathieu-Daudé <philmd@redhat.com> > Fixes: cd7498d07fbb ("s390x/pci: Add routine to get the vfio dma available count") > Signed-off-by: Cornelia Huck <cohuck@redhat.com> > Message-Id: <20201103123237.718242-1-cohuck@redhat.com> > Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> > Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> > Acked-by: Greg Kurz <groug@kaod.org> > Tested-by: Greg Kurz <groug@kaod.org> > Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> > --- > include/hw/s390x/s390-pci-vfio.h | 3 ++- > hw/s390x/meson.build | 2 +- > 2 files changed, 3 insertions(+), 2 deletions(-) I think you're missing Matt's r-b? Do you plan to send this, or should I include it on my s390-fixes branch?
Hi Cornelia, On 11/4/20 6:25 PM, Cornelia Huck wrote: > On Wed, 4 Nov 2020 12:57:03 +0100 > Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > >> From: Cornelia Huck <cohuck@redhat.com> >> >> s390-pci-vfio.c calls into the vfio code, so we need it to be >> built conditionally on vfio (which implies CONFIG_LINUX). >> >> Reported-by: Philippe Mathieu-Daudé <philmd@redhat.com> >> Fixes: cd7498d07fbb ("s390x/pci: Add routine to get the vfio dma available count") >> Signed-off-by: Cornelia Huck <cohuck@redhat.com> >> Message-Id: <20201103123237.718242-1-cohuck@redhat.com> >> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> >> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> >> Acked-by: Greg Kurz <groug@kaod.org> >> Tested-by: Greg Kurz <groug@kaod.org> >> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> >> --- >> include/hw/s390x/s390-pci-vfio.h | 3 ++- >> hw/s390x/meson.build | 2 +- >> 2 files changed, 3 insertions(+), 2 deletions(-) > > I think you're missing Matt's r-b? > > Do you plan to send this, or should I include it on my s390-fixes > branch? I plan to send a pull request with gitlab patches (or maybe they will go via Alex's testing tree) but not soon. If you are preparing s390-fixes patches, please go ahead taking this one (I only included to have the series build succeed). Thanks! Phil.
On Thu, 5 Nov 2020 12:58:01 +0100 Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > Hi Cornelia, > > On 11/4/20 6:25 PM, Cornelia Huck wrote: > > On Wed, 4 Nov 2020 12:57:03 +0100 > > Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > > > >> From: Cornelia Huck <cohuck@redhat.com> > >> > >> s390-pci-vfio.c calls into the vfio code, so we need it to be > >> built conditionally on vfio (which implies CONFIG_LINUX). > >> > >> Reported-by: Philippe Mathieu-Daudé <philmd@redhat.com> > >> Fixes: cd7498d07fbb ("s390x/pci: Add routine to get the vfio dma available count") > >> Signed-off-by: Cornelia Huck <cohuck@redhat.com> > >> Message-Id: <20201103123237.718242-1-cohuck@redhat.com> > >> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> > >> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> > >> Acked-by: Greg Kurz <groug@kaod.org> > >> Tested-by: Greg Kurz <groug@kaod.org> > >> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> > >> --- > >> include/hw/s390x/s390-pci-vfio.h | 3 ++- > >> hw/s390x/meson.build | 2 +- > >> 2 files changed, 3 insertions(+), 2 deletions(-) > > > > I think you're missing Matt's r-b? > > > > Do you plan to send this, or should I include it on my s390-fixes > > branch? > > I plan to send a pull request with gitlab patches (or maybe > they will go via Alex's testing tree) but not soon. If you > are preparing s390-fixes patches, please go ahead taking this > one (I only included to have the series build succeed). Thanks, I plan to prepare a pull req this week, so I'll just go ahead and include it.
On Donnerstag, 5. November 2020 13:23:46 CET Greg Kurz wrote: > On Thu, 5 Nov 2020 13:15:59 +0100 > > Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > > On 11/4/20 6:54 PM, Greg Kurz wrote: > > > On Wed, 04 Nov 2020 13:18:09 +0100 > > > > > > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > > >> On Mittwoch, 4. November 2020 12:57:04 CET Philippe Mathieu-Daudé wrote: > > >>> Commit b2c00bce54c ("meson: convert hw/9pfs, cleanup") introduced > > >>> CONFIG_9PFS (probably a wrong conflict resolution). This config is > > >>> not used anywhere. Backends depend on CONFIG_FSDEV_9P which itself > > >>> depends on CONFIG_VIRTFS. > > >>> > > >>> Remove the invalid CONFIG_9PFS and use CONFIG_FSDEV_9P instead, to > > >>> > > >>> fix the './configure --without-default-devices --enable-xen' build: > > >>> /usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in > > >>> function > > >>> > > >>> `xen_be_register_common': hw/xen/xen-legacy-backend.c:754: undefined > > >>> reference to `xen_9pfs_ops' /usr/bin/ld: > > >>> libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x8): undefined > > >>> reference to > > >>> `local_ops' /usr/bin/ld: > > >>> libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x20): undefined > > >>> reference > > >>> to `synth_ops' /usr/bin/ld: > > >>> libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x38): undefined > > >>> reference > > >>> to `proxy_ops' collect2: error: ld returned 1 exit status > > >>> > > >>> Fixes: b2c00bce54c ("meson: convert hw/9pfs, cleanup") > > >>> Suggested-by: Paolo Bonzini <pbonzini@redhat.com> > > >>> Acked-by: Greg Kurz <groug@kaod.org> > > >>> Tested-by: Greg Kurz <groug@kaod.org> > > >>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> > > >> > > >> Acked-by: Christian Schoenebeck <qemu_oss@crudebyte.com> > > > > > > Phil, > > > > > > Same questioning as Connie. Do you intend to get this merged or should > > > Christian or I take care of that ? > > > > Same answer too =) If you are preparing a pull request, please go ahead! > > Heh I've just seen your answer. > > Christian, > > Maybe you can add this patch in your next PR ? Yes, I will prepare a 9p PR today anyway, so I will include this patch. Best regards, Christian Schoenebeck
On Thu, 5 Nov 2020 13:01:13 +0100 Cornelia Huck <cohuck@redhat.com> wrote: > On Thu, 5 Nov 2020 12:58:01 +0100 > Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > > > Hi Cornelia, > > > > On 11/4/20 6:25 PM, Cornelia Huck wrote: > > > On Wed, 4 Nov 2020 12:57:03 +0100 > > > Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > > > > > >> From: Cornelia Huck <cohuck@redhat.com> > > >> > > >> s390-pci-vfio.c calls into the vfio code, so we need it to be > > >> built conditionally on vfio (which implies CONFIG_LINUX). > > >> > > >> Reported-by: Philippe Mathieu-Daudé <philmd@redhat.com> > > >> Fixes: cd7498d07fbb ("s390x/pci: Add routine to get the vfio dma available count") > > >> Signed-off-by: Cornelia Huck <cohuck@redhat.com> > > >> Message-Id: <20201103123237.718242-1-cohuck@redhat.com> > > >> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> > > >> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> > > >> Acked-by: Greg Kurz <groug@kaod.org> > > >> Tested-by: Greg Kurz <groug@kaod.org> > > >> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> > > >> --- > > >> include/hw/s390x/s390-pci-vfio.h | 3 ++- > > >> hw/s390x/meson.build | 2 +- > > >> 2 files changed, 3 insertions(+), 2 deletions(-) > > > > > > I think you're missing Matt's r-b? > > > > > > Do you plan to send this, or should I include it on my s390-fixes > > > branch? > > > > I plan to send a pull request with gitlab patches (or maybe > > they will go via Alex's testing tree) but not soon. If you > > are preparing s390-fixes patches, please go ahead taking this > > one (I only included to have the series build succeed). > > Thanks, I plan to prepare a pull req this week, so I'll just go ahead > and include it. Queued to s390-fixes now (with Matt's r-b included).
On Donnerstag, 5. November 2020 13:28:31 CET Christian Schoenebeck wrote: > On Donnerstag, 5. November 2020 13:23:46 CET Greg Kurz wrote: > > On Thu, 5 Nov 2020 13:15:59 +0100 > > > > Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > > > On 11/4/20 6:54 PM, Greg Kurz wrote: > > > > On Wed, 04 Nov 2020 13:18:09 +0100 > > > > > > > > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote: > > > >> On Mittwoch, 4. November 2020 12:57:04 CET Philippe Mathieu-Daudé > > wrote: > > > >>> Commit b2c00bce54c ("meson: convert hw/9pfs, cleanup") introduced > > > >>> CONFIG_9PFS (probably a wrong conflict resolution). This config is > > > >>> not used anywhere. Backends depend on CONFIG_FSDEV_9P which itself > > > >>> depends on CONFIG_VIRTFS. > > > >>> > > > >>> Remove the invalid CONFIG_9PFS and use CONFIG_FSDEV_9P instead, to > > > >>> > > > >>> fix the './configure --without-default-devices --enable-xen' build: > > > >>> /usr/bin/ld: libcommon.fa.p/hw_xen_xen-legacy-backend.c.o: in > > > >>> function > > > >>> > > > >>> `xen_be_register_common': hw/xen/xen-legacy-backend.c:754: undefined > > > >>> reference to `xen_9pfs_ops' /usr/bin/ld: > > > >>> libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x8): undefined > > > >>> reference to > > > >>> `local_ops' /usr/bin/ld: > > > >>> libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x20): undefined > > > >>> reference > > > >>> to `synth_ops' /usr/bin/ld: > > > >>> libcommon.fa.p/fsdev_qemu-fsdev.c.o:(.data.rel+0x38): undefined > > > >>> reference > > > >>> to `proxy_ops' collect2: error: ld returned 1 exit status > > > >>> > > > >>> Fixes: b2c00bce54c ("meson: convert hw/9pfs, cleanup") > > > >>> Suggested-by: Paolo Bonzini <pbonzini@redhat.com> > > > >>> Acked-by: Greg Kurz <groug@kaod.org> > > > >>> Tested-by: Greg Kurz <groug@kaod.org> > > > >>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> > > > >> > > > >> Acked-by: Christian Schoenebeck <qemu_oss@crudebyte.com> > > > > > > > > Phil, > > > > > > > > Same questioning as Connie. Do you intend to get this merged or should > > > > Christian or I take care of that ? > > > > > > Same answer too =) If you are preparing a pull request, please go ahead! > > > > Heh I've just seen your answer. > > > > Christian, > > > > Maybe you can add this patch in your next PR ? > > Yes, I will prepare a 9p PR today anyway, so I will include this patch. > > Best regards, > Christian Schoenebeck Queued on 9p.next: https://github.com/cschoenebeck/qemu/commits/9p.next Thanks! Best regards, Christian Schoenebeck