Re: [PULL 00/16] migration queue
On Mon, May 16, 2022 at 11:09:23AM +0100, Daniel P. Berrangé wrote: > On Mon, May 16, 2022 at 10:40:15AM +0100, Daniel P. Berrangé wrote: > > On Mon, May 16, 2022 at 09:51:12AM +0100, Stefan Hajnoczi wrote: > > > On Wed, May 11, 2022 at 12:40:07AM -0300, Leonardo Bras Soares Passos > > > wrote: > > > > From a previous thread: > > > > > > > > On Thu, Apr 28, 2022 at 1:20 PM Dr. David Alan Gilbert > > > > wrote: > > > > > > > > > > Leo: > > > > > Unfortunately this is failing a couple of CI tests; the MSG_ZEROCOPY > > > > > one I guess is the simpler one; I think Stefanha managed to find the > > > > > liburing fix for the __kernel_timespec case, but that looks like a bit > > > > > more fun! > > > > > > > > > > Dave > > > > > > > > I thought Stefanha had fixed this bug, and we were just waiting for a > > > > new alpine rootfs/image with that fixed. > > > > Is that correct? > > > > > > I didn't fix the liburing __kernel_timespec issue on alpine Linux. It's > > > probably a packaging bug and I gave Dave the email address of the > > > package maintainer. I'm not sure if the package maintainer has been > > > contacted or released a fixed liburing package. > > > > It was prety easy to bisect the problem with liburing so I filed a > > bug pointing to the fix needed: > > > > https://gitlab.alpinelinux.org/alpine/aports/-/issues/13813 > > Alpine win the prize for quickest distro bug fix response. The liburing > problem is now fixed in all current Alpine release streams, just minutes > after I filed the above bug. Awesome, thank you for identifying the issue and filing the issue! Stefan signature.asc Description: PGP signature
Re: [PULL 00/16] migration queue
On Mon, May 16, 2022 at 10:40:15AM +0100, Daniel P. Berrangé wrote: > On Mon, May 16, 2022 at 09:51:12AM +0100, Stefan Hajnoczi wrote: > > On Wed, May 11, 2022 at 12:40:07AM -0300, Leonardo Bras Soares Passos wrote: > > > From a previous thread: > > > > > > On Thu, Apr 28, 2022 at 1:20 PM Dr. David Alan Gilbert > > > wrote: > > > > > > > > Leo: > > > > Unfortunately this is failing a couple of CI tests; the MSG_ZEROCOPY > > > > one I guess is the simpler one; I think Stefanha managed to find the > > > > liburing fix for the __kernel_timespec case, but that looks like a bit > > > > more fun! > > > > > > > > Dave > > > > > > I thought Stefanha had fixed this bug, and we were just waiting for a > > > new alpine rootfs/image with that fixed. > > > Is that correct? > > > > I didn't fix the liburing __kernel_timespec issue on alpine Linux. It's > > probably a packaging bug and I gave Dave the email address of the > > package maintainer. I'm not sure if the package maintainer has been > > contacted or released a fixed liburing package. > > It was prety easy to bisect the problem with liburing so I filed a > bug pointing to the fix needed: > > https://gitlab.alpinelinux.org/alpine/aports/-/issues/13813 Alpine win the prize for quickest distro bug fix response. The liburing problem is now fixed in all current Alpine release streams, just minutes after I filed the above bug. With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PULL 00/16] migration queue
On Mon, May 16, 2022 at 09:51:12AM +0100, Stefan Hajnoczi wrote: > On Wed, May 11, 2022 at 12:40:07AM -0300, Leonardo Bras Soares Passos wrote: > > From a previous thread: > > > > On Thu, Apr 28, 2022 at 1:20 PM Dr. David Alan Gilbert > > wrote: > > > > > > Leo: > > > Unfortunately this is failing a couple of CI tests; the MSG_ZEROCOPY > > > one I guess is the simpler one; I think Stefanha managed to find the > > > liburing fix for the __kernel_timespec case, but that looks like a bit > > > more fun! > > > > > > Dave > > > > I thought Stefanha had fixed this bug, and we were just waiting for a > > new alpine rootfs/image with that fixed. > > Is that correct? > > I didn't fix the liburing __kernel_timespec issue on alpine Linux. It's > probably a packaging bug and I gave Dave the email address of the > package maintainer. I'm not sure if the package maintainer has been > contacted or released a fixed liburing package. It was prety easy to bisect the problem with liburing so I filed a bug pointing to the fix needed: https://gitlab.alpinelinux.org/alpine/aports/-/issues/13813 With regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PULL 00/16] migration queue
On Wed, May 11, 2022 at 12:40:07AM -0300, Leonardo Bras Soares Passos wrote: > From a previous thread: > > On Thu, Apr 28, 2022 at 1:20 PM Dr. David Alan Gilbert > wrote: > > > > Leo: > > Unfortunately this is failing a couple of CI tests; the MSG_ZEROCOPY > > one I guess is the simpler one; I think Stefanha managed to find the > > liburing fix for the __kernel_timespec case, but that looks like a bit > > more fun! > > > > Dave > > I thought Stefanha had fixed this bug, and we were just waiting for a > new alpine rootfs/image with that fixed. > Is that correct? I didn't fix the liburing __kernel_timespec issue on alpine Linux. It's probably a packaging bug and I gave Dave the email address of the package maintainer. I'm not sure if the package maintainer has been contacted or released a fixed liburing package. Stefan signature.asc Description: PGP signature
Re: [PULL 00/16] migration queue
* Leonardo Bras Soares Passos (leob...@redhat.com) wrote:
> On Wed, May 11, 2022 at 5:55 AM Dr. David Alan Gilbert
> wrote:
> >
> > * Leonardo Bras Soares Passos (leob...@redhat.com) wrote:
> > > From a previous thread:
> > >
> > > On Thu, Apr 28, 2022 at 1:20 PM Dr. David Alan Gilbert
> > > wrote:
> > > >
> > > > Leo:
> > > > Unfortunately this is failing a couple of CI tests; the MSG_ZEROCOPY
> > > > one I guess is the simpler one; I think Stefanha managed to find the
> > > > liburing fix for the __kernel_timespec case, but that looks like a bit
> > > > more fun!
> > > >
> > > > Dave
> > >
> > > I thought Stefanha had fixed this bug, and we were just waiting for a
> > > new alpine rootfs/image with that fixed.
> > > Is that correct?
> > >
> > > On Tue, May 10, 2022 at 7:43 AM Dr. David Alan Gilbert
> > > wrote:
> > > >
> > > > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > > > On Tue, May 10, 2022 at 10:58:30AM +0100, Dr. David Alan Gilbert
> > > > > wrote:
> > > [...]
> > > > >
> > > > > Yuk. That very much looks like a bug in liburing itself to me.
> > > > >
> > > > >
> > > > > We've exposed the latent bug by including linux/errqueue.h
> > > >
> > > > Yes, I think there was a thread after the 1st pull where Leo identified
> > > > the patch that fixed it; but it's not in that image.
> > >
> > > I only fixed the MSG_ZEROCOPY missing define bug, as I got that
> > > Stefanha had already fixed the issue in liburing/alpine.
> > >
> > > questions:
> > > - Has Stefanha really fixed that, and we are just waiting for a new
> > > image, or have I got that wrong?
> > > - How should I proceed with that?
> > >
> > > - If we proceed with fixing this up in alpine, will that require this
> > > patchset to be on pause until it's fixed there?
> >
> > It needs to pass in CI; so yes.
> >
> > > - If so, is there any suggestion on how to fix that in qemu code?
> > > (this header is needed because of SO_EE_* defines)
> >
> > I've not actually looked at the detail of the failure; but yes I think
> > we need a qemu workaround here.
> >
> > If there's no simple fix, then adding a test to meson.build to
> > conditionally disable liburing might be best; like the test code for
> > libcap_ng I guess (search in meson.build for libcap_ng.found at around
> > line 540.
>
> Hello Dave,
>
> I solved this issue by doing this:
>
> +linux_io_uring_test = '''
> + #include
> + #include
> +
> + int main(void) { return 0; }'''
> +
> linux_io_uring = not_found
> if not get_option('linux_io_uring').auto() or have_block
>linux_io_uring = dependency('liburing', version: '>=0.3',
>required: get_option('linux_io_uring'),
>method: 'pkg-config', kwargs: static_kwargs)
> + if not cc.links(linux_io_uring_test)
> +linux_io_uring = not_found
> + endif
> endif
> +
>
> Seems to work fine in CI, and now Alpine does not fail anymore.
> (See pipeline https://gitlab.com/LeoBras/qemu/-/pipelines/538123933
> for reference)
>
> I am not sure if this is the right thing to do, but I will be sending
> it as a full new patchset (v13), with the first patch being the one
> with the above change and the rest just carrying the recommended
> fixes.
Thanks! That looks promising. I'll cook a new pull.
> I was also thinking I could instead send the single "fix" patch, and
> recommend adding it before my v12. If that is the correct approach for
> this case, please let me know so I can improve in the future. (I am
> trying to figure out what is simpler/best for maintainers)
Either way would be fine; the full series is probably better.
Dave
> Best regards,
> Leo
>
>
>
>
>
>
>
> >
> > Dave
> >
> > > Thank you all!
> > >
> > > Best regards,
> > > Leo
> > >
> > > >
> > > > Dave
> > > >
> > > > > With regards,
> > > > > Daniel
> > > > > --
> > > > > |: https://berrange.com -o-
> > > > > https://www.flickr.com/photos/dberrange :|
> > > > > |: https://libvirt.org -o-
> > > > > https://fstop138.berrange.com :|
> > > > > |: https://entangle-photo.org-o-
> > > > > https://www.instagram.com/dberrange :|
> > > > >
> > > > --
> > > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> > > >
> > >
> > --
> > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> >
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PULL 00/16] migration queue
On Wed, May 11, 2022 at 5:55 AM Dr. David Alan Gilbert
wrote:
>
> * Leonardo Bras Soares Passos (leob...@redhat.com) wrote:
> > From a previous thread:
> >
> > On Thu, Apr 28, 2022 at 1:20 PM Dr. David Alan Gilbert
> > wrote:
> > >
> > > Leo:
> > > Unfortunately this is failing a couple of CI tests; the MSG_ZEROCOPY
> > > one I guess is the simpler one; I think Stefanha managed to find the
> > > liburing fix for the __kernel_timespec case, but that looks like a bit
> > > more fun!
> > >
> > > Dave
> >
> > I thought Stefanha had fixed this bug, and we were just waiting for a
> > new alpine rootfs/image with that fixed.
> > Is that correct?
> >
> > On Tue, May 10, 2022 at 7:43 AM Dr. David Alan Gilbert
> > wrote:
> > >
> > > * Daniel P. Berrangé (berra...@redhat.com) wrote:
> > > > On Tue, May 10, 2022 at 10:58:30AM +0100, Dr. David Alan Gilbert wrote:
> > [...]
> > > >
> > > > Yuk. That very much looks like a bug in liburing itself to me.
> > > >
> > > >
> > > > We've exposed the latent bug by including linux/errqueue.h
> > >
> > > Yes, I think there was a thread after the 1st pull where Leo identified
> > > the patch that fixed it; but it's not in that image.
> >
> > I only fixed the MSG_ZEROCOPY missing define bug, as I got that
> > Stefanha had already fixed the issue in liburing/alpine.
> >
> > questions:
> > - Has Stefanha really fixed that, and we are just waiting for a new
> > image, or have I got that wrong?
> > - How should I proceed with that?
> >
> > - If we proceed with fixing this up in alpine, will that require this
> > patchset to be on pause until it's fixed there?
>
> It needs to pass in CI; so yes.
>
> > - If so, is there any suggestion on how to fix that in qemu code?
> > (this header is needed because of SO_EE_* defines)
>
> I've not actually looked at the detail of the failure; but yes I think
> we need a qemu workaround here.
>
> If there's no simple fix, then adding a test to meson.build to
> conditionally disable liburing might be best; like the test code for
> libcap_ng I guess (search in meson.build for libcap_ng.found at around
> line 540.
Hello Dave,
I solved this issue by doing this:
+linux_io_uring_test = '''
+ #include
+ #include
+
+ int main(void) { return 0; }'''
+
linux_io_uring = not_found
if not get_option('linux_io_uring').auto() or have_block
linux_io_uring = dependency('liburing', version: '>=0.3',
required: get_option('linux_io_uring'),
method: 'pkg-config', kwargs: static_kwargs)
+ if not cc.links(linux_io_uring_test)
+linux_io_uring = not_found
+ endif
endif
+
Seems to work fine in CI, and now Alpine does not fail anymore.
(See pipeline https://gitlab.com/LeoBras/qemu/-/pipelines/538123933
for reference)
I am not sure if this is the right thing to do, but I will be sending
it as a full new patchset (v13), with the first patch being the one
with the above change and the rest just carrying the recommended
fixes.
I was also thinking I could instead send the single "fix" patch, and
recommend adding it before my v12. If that is the correct approach for
this case, please let me know so I can improve in the future. (I am
trying to figure out what is simpler/best for maintainers)
Best regards,
Leo
>
> Dave
>
> > Thank you all!
> >
> > Best regards,
> > Leo
> >
> > >
> > > Dave
> > >
> > > > With regards,
> > > > Daniel
> > > > --
> > > > |: https://berrange.com -o-
> > > > https://www.flickr.com/photos/dberrange :|
> > > > |: https://libvirt.org -o-
> > > > https://fstop138.berrange.com :|
> > > > |: https://entangle-photo.org-o-
> > > > https://www.instagram.com/dberrange :|
> > > >
> > > --
> > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
> > >
> >
> --
> Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
>
Re: [PULL 00/16] migration queue
* Leonardo Bras Soares Passos (leob...@redhat.com) wrote: > From a previous thread: > > On Thu, Apr 28, 2022 at 1:20 PM Dr. David Alan Gilbert > wrote: > > > > Leo: > > Unfortunately this is failing a couple of CI tests; the MSG_ZEROCOPY > > one I guess is the simpler one; I think Stefanha managed to find the > > liburing fix for the __kernel_timespec case, but that looks like a bit > > more fun! > > > > Dave > > I thought Stefanha had fixed this bug, and we were just waiting for a > new alpine rootfs/image with that fixed. > Is that correct? > > On Tue, May 10, 2022 at 7:43 AM Dr. David Alan Gilbert > wrote: > > > > * Daniel P. Berrangé (berra...@redhat.com) wrote: > > > On Tue, May 10, 2022 at 10:58:30AM +0100, Dr. David Alan Gilbert wrote: > [...] > > > > > > Yuk. That very much looks like a bug in liburing itself to me. > > > > > > > > > We've exposed the latent bug by including linux/errqueue.h > > > > Yes, I think there was a thread after the 1st pull where Leo identified > > the patch that fixed it; but it's not in that image. > > I only fixed the MSG_ZEROCOPY missing define bug, as I got that > Stefanha had already fixed the issue in liburing/alpine. > > questions: > - Has Stefanha really fixed that, and we are just waiting for a new > image, or have I got that wrong? > - How should I proceed with that? > > - If we proceed with fixing this up in alpine, will that require this > patchset to be on pause until it's fixed there? It needs to pass in CI; so yes. > - If so, is there any suggestion on how to fix that in qemu code? > (this header is needed because of SO_EE_* defines) I've not actually looked at the detail of the failure; but yes I think we need a qemu workaround here. If there's no simple fix, then adding a test to meson.build to conditionally disable liburing might be best; like the test code for libcap_ng I guess (search in meson.build for libcap_ng.found at around line 540. Dave > Thank you all! > > Best regards, > Leo > > > > > Dave > > > > > With regards, > > > Daniel > > > -- > > > |: https://berrange.com -o- > > > https://www.flickr.com/photos/dberrange :| > > > |: https://libvirt.org -o- > > > https://fstop138.berrange.com :| > > > |: https://entangle-photo.org-o- > > > https://www.instagram.com/dberrange :| > > > > > -- > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > > > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PULL 00/16] migration queue
>From a previous thread: On Thu, Apr 28, 2022 at 1:20 PM Dr. David Alan Gilbert wrote: > > Leo: > Unfortunately this is failing a couple of CI tests; the MSG_ZEROCOPY > one I guess is the simpler one; I think Stefanha managed to find the > liburing fix for the __kernel_timespec case, but that looks like a bit > more fun! > > Dave I thought Stefanha had fixed this bug, and we were just waiting for a new alpine rootfs/image with that fixed. Is that correct? On Tue, May 10, 2022 at 7:43 AM Dr. David Alan Gilbert wrote: > > * Daniel P. Berrangé (berra...@redhat.com) wrote: > > On Tue, May 10, 2022 at 10:58:30AM +0100, Dr. David Alan Gilbert wrote: [...] > > > > Yuk. That very much looks like a bug in liburing itself to me. > > > > > > We've exposed the latent bug by including linux/errqueue.h > > Yes, I think there was a thread after the 1st pull where Leo identified > the patch that fixed it; but it's not in that image. I only fixed the MSG_ZEROCOPY missing define bug, as I got that Stefanha had already fixed the issue in liburing/alpine. questions: - Has Stefanha really fixed that, and we are just waiting for a new image, or have I got that wrong? - How should I proceed with that? - If we proceed with fixing this up in alpine, will that require this patchset to be on pause until it's fixed there? - If so, is there any suggestion on how to fix that in qemu code? (this header is needed because of SO_EE_* defines) Thank you all! Best regards, Leo > > Dave > > > With regards, > > Daniel > > -- > > |: https://berrange.com -o-https://www.flickr.com/photos/dberrange > > :| > > |: https://libvirt.org -o-https://fstop138.berrange.com > > :| > > |: https://entangle-photo.org-o-https://www.instagram.com/dberrange > > :| > > > -- > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK >
Re: [PULL 00/16] migration queue
* Daniel P. Berrangé (berra...@redhat.com) wrote:
> On Tue, May 10, 2022 at 10:58:30AM +0100, Dr. David Alan Gilbert wrote:
> > * Dr. David Alan Gilbert (git) (dgilb...@redhat.com) wrote:
> > > From: "Dr. David Alan Gilbert"
> > >
> > > The following changes since commit
> > > 178bacb66d98d9ee7a702b9f2a4dfcd88b72a9ab:
> > >
> > > Merge tag 'block-pull-request' of https://gitlab.com/stefanha/qemu into
> > > staging (2022-05-09 11:07:04 -0700)
> > >
> > > are available in the Git repository at:
> > >
> > > https://gitlab.com/dagrh/qemu.git tags/pull-migration-20220510a
> > >
> > > for you to fetch changes up to 511f4a0506af1d380115a61f3362149953646871:
> > >
> > > multifd: Implement zero copy write in multifd migration
> > > (multifd-zero-copy) (2022-05-10 09:15:06 +0100)
> >
> > Nack
> > This is still failing the Alpine build test:
> >
> > ninja: job failed: cc -m64 -mcx16 -Ilibio.fa.p -I. -I.. -Iqapi -Itrace -Iui
> > -Iui/shader -I/usr/include/p11-kit-1 -I/usr/include/glib-2.0
> > -I/usr/lib/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch
> > -Werror -std=gnu11 -O2 -g -isystem /builds/dagrh/qemu/linux-headers
> > -isystem linux-headers -iquote . -iquote /builds/dagrh/qemu -iquote
> > /builds/dagrh/qemu/include -iquote /builds/dagrh/qemu/disas/libvixl -iquote
> > /builds/dagrh/qemu/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
> > -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> > -Wstrict-prototypes -Wredundant-decls -Wundef -Wwrite-strings
> > -Wmissing-prototypes -fno-strict-aliasing -fno-common -fwrapv
> > -Wold-style-declaration -Wold-style-definition -Wtype-limits
> > -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers
> > -Wempty-body -Wnested-externs -Wendif-labels -Wexpansion-to-defined
> > -Wimplicit-fallthrough=2 -Wno-missing-include-dirs
> > -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -MD -MQ
> > libio.fa.p/io_channel-socket.c.o -MF libio.fa.p/io_channel-socket.c.o.d -o
> > libio.fa.p/io_channel-socket.c.o -c ../io/channel-socket.c
> > In file included from /usr/include/linux/errqueue.h:6,
> > from ../io/channel-socket.c:29:
> > /usr/include/linux/time_types.h:7:8: error: redefinition of 'struct
> > __kernel_timespec'
> > 7 | struct __kernel_timespec {
> > |^
> > In file included from /usr/include/liburing.h:19,
> > from /builds/dagrh/qemu/include/block/aio.h:18,
> > from /builds/dagrh/qemu/include/io/channel.h:26,
> > from /builds/dagrh/qemu/include/io/channel-socket.h:24,
> > from ../io/channel-socket.c:24:
> > /usr/include/liburing/compat.h:9:8: note: originally defined here
> > 9 | struct __kernel_timespec {
> > |^
> > ninja: subcommand failed
> > make: *** [Makefile:163: run-ninja] Error 1
>
> Yuk. That very much looks like a bug in liburing itself to me.
>
>
> We've exposed the latent bug by including linux/errqueue.h
Yes, I think there was a thread after the 1st pull where Leo identified
the patch that fixed it; but it's not in that image.
Dave
> With regards,
> Daniel
> --
> |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org -o-https://fstop138.berrange.com :|
> |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
>
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PULL 00/16] migration queue
On Tue, May 10, 2022 at 10:58:30AM +0100, Dr. David Alan Gilbert wrote:
> * Dr. David Alan Gilbert (git) (dgilb...@redhat.com) wrote:
> > From: "Dr. David Alan Gilbert"
> >
> > The following changes since commit 178bacb66d98d9ee7a702b9f2a4dfcd88b72a9ab:
> >
> > Merge tag 'block-pull-request' of https://gitlab.com/stefanha/qemu into
> > staging (2022-05-09 11:07:04 -0700)
> >
> > are available in the Git repository at:
> >
> > https://gitlab.com/dagrh/qemu.git tags/pull-migration-20220510a
> >
> > for you to fetch changes up to 511f4a0506af1d380115a61f3362149953646871:
> >
> > multifd: Implement zero copy write in multifd migration
> > (multifd-zero-copy) (2022-05-10 09:15:06 +0100)
>
> Nack
> This is still failing the Alpine build test:
>
> ninja: job failed: cc -m64 -mcx16 -Ilibio.fa.p -I. -I.. -Iqapi -Itrace -Iui
> -Iui/shader -I/usr/include/p11-kit-1 -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch
> -Werror -std=gnu11 -O2 -g -isystem /builds/dagrh/qemu/linux-headers -isystem
> linux-headers -iquote . -iquote /builds/dagrh/qemu -iquote
> /builds/dagrh/qemu/include -iquote /builds/dagrh/qemu/disas/libvixl -iquote
> /builds/dagrh/qemu/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
> -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
> -Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes
> -fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration
> -Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k
> -Winit-self -Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels
> -Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs
> -Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -MD -MQ
> libio.fa.p/io_channel-socket.c.o -MF libio.fa.p/io_channel-socket.c.o.d -o
> libio.fa.p/io_channel-socket.c.o -c ../io/channel-socket.c
> In file included from /usr/include/linux/errqueue.h:6,
> from ../io/channel-socket.c:29:
> /usr/include/linux/time_types.h:7:8: error: redefinition of 'struct
> __kernel_timespec'
> 7 | struct __kernel_timespec {
> |^
> In file included from /usr/include/liburing.h:19,
> from /builds/dagrh/qemu/include/block/aio.h:18,
> from /builds/dagrh/qemu/include/io/channel.h:26,
> from /builds/dagrh/qemu/include/io/channel-socket.h:24,
> from ../io/channel-socket.c:24:
> /usr/include/liburing/compat.h:9:8: note: originally defined here
> 9 | struct __kernel_timespec {
> |^
> ninja: subcommand failed
> make: *** [Makefile:163: run-ninja] Error 1
Yuk. That very much looks like a bug in liburing itself to me.
We've exposed the latent bug by including linux/errqueue.h
With regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
Re: [PULL 00/16] migration queue
* Dr. David Alan Gilbert (git) (dgilb...@redhat.com) wrote:
> From: "Dr. David Alan Gilbert"
>
> The following changes since commit 178bacb66d98d9ee7a702b9f2a4dfcd88b72a9ab:
>
> Merge tag 'block-pull-request' of https://gitlab.com/stefanha/qemu into
> staging (2022-05-09 11:07:04 -0700)
>
> are available in the Git repository at:
>
> https://gitlab.com/dagrh/qemu.git tags/pull-migration-20220510a
>
> for you to fetch changes up to 511f4a0506af1d380115a61f3362149953646871:
>
> multifd: Implement zero copy write in multifd migration (multifd-zero-copy)
> (2022-05-10 09:15:06 +0100)
Nack
This is still failing the Alpine build test:
ninja: job failed: cc -m64 -mcx16 -Ilibio.fa.p -I. -I.. -Iqapi -Itrace -Iui
-Iui/shader -I/usr/include/p11-kit-1 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -fdiagnostics-color=auto -Wall -Winvalid-pch
-Werror -std=gnu11 -O2 -g -isystem /builds/dagrh/qemu/linux-headers -isystem
linux-headers -iquote . -iquote /builds/dagrh/qemu -iquote
/builds/dagrh/qemu/include -iquote /builds/dagrh/qemu/disas/libvixl -iquote
/builds/dagrh/qemu/tcg/i386 -pthread -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wundef -Wwrite-strings -Wmissing-prototypes
-fno-strict-aliasing -fno-common -fwrapv -Wold-style-declaration
-Wold-style-definition -Wtype-limits -Wformat-security -Wformat-y2k -Winit-self
-Wignored-qualifiers -Wempty-body -Wnested-externs -Wendif-labels
-Wexpansion-to-defined -Wimplicit-fallthrough=2 -Wno-missing-include-dirs
-Wno-shift-negative-value -Wno-psabi -fstack-protector-strong -fPIE -MD -MQ
libio.fa.p/io_channel-socket.c.o -MF libio.fa.p/io_channel-socket.c.o.d -o
libio.fa.p/io_channel-socket.c.o -c ../io/channel-socket.c
In file included from /usr/include/linux/errqueue.h:6,
from ../io/channel-socket.c:29:
/usr/include/linux/time_types.h:7:8: error: redefinition of 'struct
__kernel_timespec'
7 | struct __kernel_timespec {
|^
In file included from /usr/include/liburing.h:19,
from /builds/dagrh/qemu/include/block/aio.h:18,
from /builds/dagrh/qemu/include/io/channel.h:26,
from /builds/dagrh/qemu/include/io/channel-socket.h:24,
from ../io/channel-socket.c:24:
/usr/include/liburing/compat.h:9:8: note: originally defined here
9 | struct __kernel_timespec {
|^
ninja: subcommand failed
make: *** [Makefile:163: run-ninja] Error 1
>
> Migration pull 2022-05-10
>
> This replaces yesterdays and the pull originally sent on 28th April;
> compared to yesterdays this fixes an accidental change to skiboot.
>
> It contains:
> TLS test fixes from Dan
> Zerocopy migration feature from Leo
>
> Signed-off-by: Dr. David Alan Gilbert
>
>
> Daniel P. Berrangé (9):
> tests: fix encoding of IP addresses in x509 certs
> tests: add more helper macros for creating TLS x509 certs
> tests: add migration tests of TLS with PSK credentials
> tests: add migration tests of TLS with x509 credentials
> tests: convert XBZRLE migration test to use common helper
> tests: convert multifd migration tests to use common helper
> tests: add multifd migration tests of TLS with PSK credentials
> tests: add multifd migration tests of TLS with x509 credentials
> tests: ensure migration status isn't reported as failed
>
> Leonardo Bras (7):
> QIOChannel: Add flags on io_writev and introduce io_flush callback
> QIOChannelSocket: Implement io_writev zero copy flag & io_flush for
> CONFIG_LINUX
> migration: Add zero-copy-send parameter for QMP/HMP for Linux
> migration: Add migrate_use_tls() helper
> multifd: multifd_send_sync_main now returns negative on error
> multifd: Send header packet without flags if zero-copy-send is enabled
> multifd: Implement zero copy write in multifd migration
> (multifd-zero-copy)
>
> chardev/char-io.c| 2 +-
> hw/remote/mpqemu-link.c | 2 +-
> include/io/channel-socket.h | 2 +
> include/io/channel.h | 38 +-
> io/channel-buffer.c | 1 +
> io/channel-command.c | 1 +
> io/channel-file.c| 1 +
> io/channel-socket.c | 118 -
> io/channel-tls.c | 1 +
> io/channel-websock.c | 1 +
> io/channel.c | 49 +-
> meson.build | 1 +
> migration/channel.c | 3 +-
> migration/migration.c| 52 ++-
> migration/migration.h| 6 +
> migration/multifd.c | 74 ++-
> migration/multifd.h | 4
Re: [PULL 00/16] migration queue
On Samstag, 31. Oktober 2020 20:10:49 CET Christian Schoenebeck wrote: > On Samstag, 31. Oktober 2020 18:46:11 CET Peter Xu wrote: > > On Sat, Oct 31, 2020 at 05:26:28PM +, Peter Maydell wrote: > > > On Sat, 31 Oct 2020 at 16:12, Christian Schoenebeck > > > > > > wrote: > > > > On Montag, 26. Oktober 2020 17:19:36 CET Dr. David Alan Gilbert (git) > > wrote: > > > > > > > > > > migration pull: 2020-10-26 > > > > > > > > > > Another go at Peter's postcopy fixes > > > > > > > > > > Cleanups from Bihong Yu and Peter Maydell. > > > > > > > > > > Signed-off-by: Dr. David Alan Gilbert > > > > > > > > May it be possible that this PR introduced a lockup of the qtests that > > > > I > > > > am > > > > encountering in this week's upstream revisions? > > > > > > If you try the patches Peter Xu attached to this thread > > > does the lockup go away ? > > > > > > https://lore.kernel.org/qemu-devel/20201030135350.GA588069@xz-x1/ > > > > > > (I'm also seeing intermittent hangs, for some reason almost always > > > on s390x host.) > > > > It would be good to know exactly which test hanged. If it's > > migration-test > > then it's very possible. > > It's run-test-144 that does not return; according to Makefile.mtest that's > migration-test, so chances are high that it's indeed introduced by this PR. > > > The race above patch(es) tried to fix should logically be reproducable on > > all archs, not s390x only. > > > > Thanks, > > Yes, it's i386 here that locks up. > > I'm running the loop with your patches now, so far so good, let's see if > it's still alive tomorrow. > > Best regards, > Christian Schoenebeck Looks good! 16h later and the loop is still running here; it also made the lockup to disappear on Travis-CI. So Peter Xu's two patches fix the lockup problem for me. Best regards, Christian Schoenebeck
Re: [PULL 00/16] migration queue
On Samstag, 31. Oktober 2020 18:46:11 CET Peter Xu wrote: > On Sat, Oct 31, 2020 at 05:26:28PM +, Peter Maydell wrote: > > On Sat, 31 Oct 2020 at 16:12, Christian Schoenebeck > > > > wrote: > > > On Montag, 26. Oktober 2020 17:19:36 CET Dr. David Alan Gilbert (git) wrote: > > > > > > > > migration pull: 2020-10-26 > > > > > > > > Another go at Peter's postcopy fixes > > > > > > > > Cleanups from Bihong Yu and Peter Maydell. > > > > > > > > Signed-off-by: Dr. David Alan Gilbert > > > > > > May it be possible that this PR introduced a lockup of the qtests that I > > > am > > > encountering in this week's upstream revisions? > > > > If you try the patches Peter Xu attached to this thread > > does the lockup go away ? > > > > https://lore.kernel.org/qemu-devel/20201030135350.GA588069@xz-x1/ > > > > (I'm also seeing intermittent hangs, for some reason almost always > > on s390x host.) > > It would be good to know exactly which test hanged. If it's migration-test > then it's very possible. It's run-test-144 that does not return; according to Makefile.mtest that's migration-test, so chances are high that it's indeed introduced by this PR. > The race above patch(es) tried to fix should logically be reproducable on > all archs, not s390x only. > > Thanks, Yes, it's i386 here that locks up. I'm running the loop with your patches now, so far so good, let's see if it's still alive tomorrow. Best regards, Christian Schoenebeck
Re: [PULL 00/16] migration queue
On Sat, Oct 31, 2020 at 05:26:28PM +, Peter Maydell wrote: > On Sat, 31 Oct 2020 at 16:12, Christian Schoenebeck > wrote: > > > > On Montag, 26. Oktober 2020 17:19:36 CET Dr. David Alan Gilbert (git) wrote: > > > > > > migration pull: 2020-10-26 > > > > > > Another go at Peter's postcopy fixes > > > > > > Cleanups from Bihong Yu and Peter Maydell. > > > > > > Signed-off-by: Dr. David Alan Gilbert > > > > > > > May it be possible that this PR introduced a lockup of the qtests that I am > > encountering in this week's upstream revisions? > > If you try the patches Peter Xu attached to this thread > does the lockup go away ? > > https://lore.kernel.org/qemu-devel/20201030135350.GA588069@xz-x1/ > > (I'm also seeing intermittent hangs, for some reason almost always > on s390x host.) It would be good to know exactly which test hanged. If it's migration-test then it's very possible. The race above patch(es) tried to fix should logically be reproducable on all archs, not s390x only. Thanks, -- Peter Xu
Re: [PULL 00/16] migration queue
On Sat, 31 Oct 2020 at 16:12, Christian Schoenebeck wrote: > > On Montag, 26. Oktober 2020 17:19:36 CET Dr. David Alan Gilbert (git) wrote: > > > > migration pull: 2020-10-26 > > > > Another go at Peter's postcopy fixes > > > > Cleanups from Bihong Yu and Peter Maydell. > > > > Signed-off-by: Dr. David Alan Gilbert > > > > May it be possible that this PR introduced a lockup of the qtests that I am > encountering in this week's upstream revisions? If you try the patches Peter Xu attached to this thread does the lockup go away ? https://lore.kernel.org/qemu-devel/20201030135350.GA588069@xz-x1/ (I'm also seeing intermittent hangs, for some reason almost always on s390x host.) thanks -- PMM
Re: [PULL 00/16] migration queue
On Montag, 26. Oktober 2020 17:19:36 CET Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert"
>
> The following changes since commit a46e72710566eea0f90f9c673a0f02da0064acce:
>
> Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20201026' into
> staging (2020-10-26 14:50:03 +)
>
> are available in the Git repository at:
>
> git://github.com/dagrh/qemu.git tags/pull-migration-20201026a
>
> for you to fetch changes up to a47295014de56e108f359ec859d5499b851f62b8:
>
> migration-test: Only hide error if !QTEST_LOG (2020-10-26 16:15:04 +)
>
>
> migration pull: 2020-10-26
>
> Another go at Peter's postcopy fixes
>
> Cleanups from Bihong Yu and Peter Maydell.
>
> Signed-off-by: Dr. David Alan Gilbert
>
May it be possible that this PR introduced a lockup of the qtests that I am
encountering in this week's upstream revisions?
PASS 25 qtest-x86_64/bios-tables-test /x86_64/acpi/microvm/pcie
Looking for expected file 'tests/data/acpi/microvm/FACP.rtc'
Looking for expected file 'tests/data/acpi/microvm/FACP'
Using expected file 'tests/data/acpi/microvm/FACP'
Looking for expected file 'tests/data/acpi/microvm/APIC.rtc'
Looking for expected file 'tests/data/acpi/microvm/APIC'
Using expected file 'tests/data/acpi/microvm/APIC'
Looking for expected file 'tests/data/acpi/microvm/DSDT.rtc'
Using expected file 'tests/data/acpi/microvm/DSDT.rtc'
PASS 24 qtest-i386/bios-tables-test /i386/acpi/microvm/rtc
PASS 15 qtest-i386/migration-test /i386/migration/multifd/tcp/cancel
PASS 16 qtest-i386/migration-test /i386/migration/multifd/tcp/zlib
^Cmake: *** [Makefile.mtest:1169: run-test-144] Interrupt
I tried to bisect the causing commit and came up to this PR merge. But I'm not
absolutely sure it really is, because it sometimes takes 2 hours or more to
trigger the lockup, so the relevant commit may as well have slipped during
bisection.
Last week's revisions run here for >24h without issues, right now I get
lockups of test runs after ~3min .. ~2h when running the qtests in an endless
loop:
#/bin/sh
i=0
while true; do
i=$[$i+1]
echo '**'
echo "* RUN $i *"
echo '**'
make check-qtest -j32 V=1
if [[ "$?" -ne 0 ]]; then
echo "Aborted after $i runs due to failure"
break
fi
done
>
> Bihong Yu (9):
> migration: Do not use C99 // comments
> migration: Don't use '#' flag of printf format
> migration: Add spaces around operator
> migration: Open brace '{' following struct go on the same line
> migration: Add braces {} for if statement
> migration: Do not initialise statics and globals to 0 or NULL
> migration: Open brace '{' following function declarations go on the
> next line migration: Delete redundant spaces
> migration: using trace_ to replace DPRINTF
>
> Peter Maydell (1):
> migration: Drop unused VMSTATE_FLOAT64 support
>
> Peter Xu (6):
> migration: Pass incoming state into qemu_ufd_copy_ioctl()
> migration: Introduce migrate_send_rp_message_req_pages()
> migration: Maintain postcopy faulted addresses
> migration: Sync requested pages after postcopy recovery
> migration/postcopy: Release fd before going into 'postcopy-pause'
> migration-test: Only hide error if !QTEST_LOG
>
> include/migration/vmstate.h | 13 --
> migration/block.c| 40 ++---
> migration/migration.c| 59
> +- migration/migration.h|
> 24 ++---
> migration/page_cache.c | 13 +++---
> migration/postcopy-ram.c | 27 +++-
> migration/ram.c | 14 +-
> migration/rdma.c | 7 ++---
> migration/savevm.c | 61
> ++-- migration/trace-events |
> 16
> migration/vmstate-types.c| 26 ---
> migration/vmstate.c | 10
> tests/qtest/migration-test.c | 6 -
> 13 files changed, 213 insertions(+), 103 deletions(-)
Re: [PULL 00/16] migration queue
On Mon, 26 Oct 2020 at 16:20, Dr. David Alan Gilbert (git) wrote: > > From: "Dr. David Alan Gilbert" > > The following changes since commit a46e72710566eea0f90f9c673a0f02da0064acce: > > Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20201026' into > staging (2020-10-26 14:50:03 +) > > are available in the Git repository at: > > git://github.com/dagrh/qemu.git tags/pull-migration-20201026a > > for you to fetch changes up to a47295014de56e108f359ec859d5499b851f62b8: > > migration-test: Only hide error if !QTEST_LOG (2020-10-26 16:15:04 +) > > > migration pull: 2020-10-26 > > Another go at Peter's postcopy fixes > > Cleanups from Bihong Yu and Peter Maydell. > > Signed-off-by: Dr. David Alan Gilbert > Applied, thanks. Please update the changelog at https://wiki.qemu.org/ChangeLog/5.2 for any user-visible changes. -- PMM
Re: [PULL 00/16] migration queue
* no-re...@patchew.org (no-re...@patchew.org) wrote:
> Patchew URL:
> https://patchew.org/QEMU/20201026161952.149188-1-dgilb...@redhat.com/
>
>
>
> Hi,
>
> This series seems to have some coding style problems. See output below for
> more information:
>
> Type: series
> Message-id: 20201026161952.149188-1-dgilb...@redhat.com
> Subject: [PULL 00/16] migration queue
>
> === TEST SCRIPT BEGIN ===
> #!/bin/bash
> git rev-parse base > /dev/null || exit 0
> git config --local diff.renamelimit 0
> git config --local diff.renames True
> git config --local diff.algorithm histogram
> ./scripts/checkpatch.pl --mailback base..
> === TEST SCRIPT END ===
>
> Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
> From https://github.com/patchew-project/qemu
> - [tag update]
> patchew/1603704987-20977-1-git-send-email-kwankh...@nvidia.com ->
> patchew/1603704987-20977-1-git-send-email-kwankh...@nvidia.com
> * [new tag] patchew/20201026161952.149188-1-dgilb...@redhat.com ->
> patchew/20201026161952.149188-1-dgilb...@redhat.com
> Switched to a new branch 'test'
> eec7173 migration-test: Only hide error if !QTEST_LOG
> 3cf5619 migration/postcopy: Release fd before going into 'postcopy-pause'
> 05826d6 migration: Sync requested pages after postcopy recovery
> e3ab9bd migration: Maintain postcopy faulted addresses
> 94c47fd migration: Introduce migrate_send_rp_message_req_pages()
> 37f5d13 migration: Pass incoming state into qemu_ufd_copy_ioctl()
> d212778 migration: using trace_ to replace DPRINTF
> 57fda59 migration: Delete redundant spaces
> 5b093f1 migration: Open brace '{' following function declarations go on the
> next line
> 0b60dca migration: Do not initialise statics and globals to 0 or NULL
> 2f219b6 migration: Add braces {} for if statement
> 3fdcabc migration: Open brace '{' following struct go on the same line
> 63bb26e migration: Add spaces around operator
> fadaa39 migration: Don't use '#' flag of printf format
> e568828 migration: Do not use C99 // comments
> e477d01 migration: Drop unused VMSTATE_FLOAT64 support
>
> === OUTPUT BEGIN ===
> 1/16 Checking commit e477d010bf93 (migration: Drop unused VMSTATE_FLOAT64
> support)
> 2/16 Checking commit e568828c0e63 (migration: Do not use C99 // comments)
> 3/16 Checking commit fadaa39cfb42 (migration: Don't use '#' flag of printf
> format)
> 4/16 Checking commit 63bb26e930c4 (migration: Add spaces around operator)
> ERROR: spaces required around that '*' (ctx:WxV)
> #65: FILE: migration/savevm.c:523:
> +.subsections = (const VMStateDescription *[]) {
> ^
>
> total: 1 errors, 0 warnings, 59 lines checked
We decided that was preferable
>
> Patch 4/16 has style problems, please review. If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
>
> 5/16 Checking commit 3fdcabce2015 (migration: Open brace '{' following struct
> go on the same line)
> 6/16 Checking commit 2f219b67cf64 (migration: Add braces {} for if statement)
> 7/16 Checking commit 0b60dca56f19 (migration: Do not initialise statics and
> globals to 0 or NULL)
> 8/16 Checking commit 5b093f15f482 (migration: Open brace '{' following
> function declarations go on the next line)
> 9/16 Checking commit 57fda592d44b (migration: Delete redundant spaces)
> 10/16 Checking commit d21277810b4a (migration: using trace_ to replace
> DPRINTF)
> 11/16 Checking commit 37f5d13fa1bb (migration: Pass incoming state into
> qemu_ufd_copy_ioctl())
> 12/16 Checking commit 94c47fdc32f4 (migration: Introduce
> migrate_send_rp_message_req_pages())
> 13/16 Checking commit e3ab9bded382 (migration: Maintain postcopy faulted
> addresses)
> 14/16 Checking commit 05826d6ec62a (migration: Sync requested pages after
> postcopy recovery)
> 15/16 Checking commit 3cf5619e375b (migration/postcopy: Release fd before
> going into 'postcopy-pause')
> 16/16 Checking commit eec7173d989d (migration-test: Only hide error if
> !QTEST_LOG)
> === OUTPUT END ===
>
> Test command exited with code: 1
>
>
> The full log is available at
> http://patchew.org/logs/20201026161952.149188-1-dgilb...@redhat.com/testing.checkpatch/?type=message.
> ---
> Email generated automatically by Patchew [https://patchew.org/].
> Please send your feedback to patchew-de...@redhat.com
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
Re: [PULL 00/16] migration queue
Patchew URL:
https://patchew.org/QEMU/20201026161952.149188-1-dgilb...@redhat.com/
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20201026161952.149188-1-dgilb...@redhat.com
Subject: [PULL 00/16] migration queue
=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===
Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
- [tag update]
patchew/1603704987-20977-1-git-send-email-kwankh...@nvidia.com ->
patchew/1603704987-20977-1-git-send-email-kwankh...@nvidia.com
* [new tag] patchew/20201026161952.149188-1-dgilb...@redhat.com ->
patchew/20201026161952.149188-1-dgilb...@redhat.com
Switched to a new branch 'test'
eec7173 migration-test: Only hide error if !QTEST_LOG
3cf5619 migration/postcopy: Release fd before going into 'postcopy-pause'
05826d6 migration: Sync requested pages after postcopy recovery
e3ab9bd migration: Maintain postcopy faulted addresses
94c47fd migration: Introduce migrate_send_rp_message_req_pages()
37f5d13 migration: Pass incoming state into qemu_ufd_copy_ioctl()
d212778 migration: using trace_ to replace DPRINTF
57fda59 migration: Delete redundant spaces
5b093f1 migration: Open brace '{' following function declarations go on the
next line
0b60dca migration: Do not initialise statics and globals to 0 or NULL
2f219b6 migration: Add braces {} for if statement
3fdcabc migration: Open brace '{' following struct go on the same line
63bb26e migration: Add spaces around operator
fadaa39 migration: Don't use '#' flag of printf format
e568828 migration: Do not use C99 // comments
e477d01 migration: Drop unused VMSTATE_FLOAT64 support
=== OUTPUT BEGIN ===
1/16 Checking commit e477d010bf93 (migration: Drop unused VMSTATE_FLOAT64
support)
2/16 Checking commit e568828c0e63 (migration: Do not use C99 // comments)
3/16 Checking commit fadaa39cfb42 (migration: Don't use '#' flag of printf
format)
4/16 Checking commit 63bb26e930c4 (migration: Add spaces around operator)
ERROR: spaces required around that '*' (ctx:WxV)
#65: FILE: migration/savevm.c:523:
+.subsections = (const VMStateDescription *[]) {
^
total: 1 errors, 0 warnings, 59 lines checked
Patch 4/16 has style problems, please review. If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
5/16 Checking commit 3fdcabce2015 (migration: Open brace '{' following struct
go on the same line)
6/16 Checking commit 2f219b67cf64 (migration: Add braces {} for if statement)
7/16 Checking commit 0b60dca56f19 (migration: Do not initialise statics and
globals to 0 or NULL)
8/16 Checking commit 5b093f15f482 (migration: Open brace '{' following function
declarations go on the next line)
9/16 Checking commit 57fda592d44b (migration: Delete redundant spaces)
10/16 Checking commit d21277810b4a (migration: using trace_ to replace DPRINTF)
11/16 Checking commit 37f5d13fa1bb (migration: Pass incoming state into
qemu_ufd_copy_ioctl())
12/16 Checking commit 94c47fdc32f4 (migration: Introduce
migrate_send_rp_message_req_pages())
13/16 Checking commit e3ab9bded382 (migration: Maintain postcopy faulted
addresses)
14/16 Checking commit 05826d6ec62a (migration: Sync requested pages after
postcopy recovery)
15/16 Checking commit 3cf5619e375b (migration/postcopy: Release fd before going
into 'postcopy-pause')
16/16 Checking commit eec7173d989d (migration-test: Only hide error if
!QTEST_LOG)
=== OUTPUT END ===
Test command exited with code: 1
The full log is available at
http://patchew.org/logs/20201026161952.149188-1-dgilb...@redhat.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com
