[PULL for-7.0 0/2] Block patches

[PULL for-7.0 0/2] Block patches

[Stefan Hajnoczi]

The following changes since commit 1d60bb4b14601e38ed17384277aa4c30c57925d3:

  Merge tag 'pull-request-2022-03-15v2' of https://gitlab.com/thuth/qemu into staging (2022-03-16 10:43:58 +0000)

are available in the Git repository at:

  https://gitlab.com/stefanha/qemu.git tags/block-pull-request

for you to fetch changes up to fc8796465c6cd4091efe6a2f8b353f07324f49c7:

  aio-posix: fix spurious ->poll_ready() callbacks in main loop (2022-03-17 11:23:18 +0000)

----------------------------------------------------------------
Pull request

Bug fixes for 7.0.

----------------------------------------------------------------

Haiyue Wang (1):
  aio-posix: fix build failure io_uring 2.2

Stefan Hajnoczi (1):
  aio-posix: fix spurious ->poll_ready() callbacks in main loop

 util/aio-posix.h      |  1 +
 util/aio-posix.c      | 32 ++++++++++++++++++--------------
 util/fdmon-io_uring.c |  4 ++++
 3 files changed, 23 insertions(+), 14 deletions(-)

-- 
2.35.1

[PULL for-7.0 1/2] aio-posix: fix build failure io_uring 2.2

[Stefan Hajnoczi]

From: Haiyue Wang <haiyue.wang@intel.com>

The io_uring fixed "Don't truncate addr fields to 32-bit on 32-bit":
https://git.kernel.dk/cgit/liburing/commit/?id=d84c29b19ed0b130000619cff40141bb1fc3615b

This leads to build failure:
../util/fdmon-io_uring.c: In function ‘add_poll_remove_sqe’:
../util/fdmon-io_uring.c:182:36: error: passing argument 2 of ‘io_uring_prep_poll_remove’ makes integer from pointer without a cast [-Werror=int-conversion]
  182 |     io_uring_prep_poll_remove(sqe, node);
      |                                    ^~~~
      |                                    |
      |                                    AioHandler *
In file included from /root/io/qemu/include/block/aio.h:18,
                 from ../util/aio-posix.h:20,
                 from ../util/fdmon-io_uring.c:49:
/usr/include/liburing.h:415:17: note: expected ‘__u64’ {aka ‘long long unsigned int’} but argument is of type ‘AioHandler *’
  415 |           __u64 user_data)
      |           ~~~~~~^~~~~~~~~
cc1: all warnings being treated as errors

Use LIBURING_HAVE_DATA64 to check whether the io_uring supports 64-bit
variants of the get/set userdata, to convert the paramter to the right
data type.

Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
Message-Id: <20220221162401.45415-1-haiyue.wang@intel.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 util/fdmon-io_uring.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/util/fdmon-io_uring.c b/util/fdmon-io_uring.c
index 1461dfa407..ab43052dd7 100644
--- a/util/fdmon-io_uring.c
+++ b/util/fdmon-io_uring.c
@@ -179,7 +179,11 @@ static void add_poll_remove_sqe(AioContext *ctx, AioHandler *node)
 {
     struct io_uring_sqe *sqe = get_sqe(ctx);
 
+#ifdef LIBURING_HAVE_DATA64
+    io_uring_prep_poll_remove(sqe, (__u64)(uintptr_t)node);
+#else
     io_uring_prep_poll_remove(sqe, node);
+#endif
 }
 
 /* Add a timeout that self-cancels when another cqe becomes ready */
-- 
2.35.1

[PULL for-7.0 2/2] aio-posix: fix spurious ->poll_ready() callbacks in main loop

[Stefan Hajnoczi]

When ->poll() succeeds the AioHandler is placed on the ready list with
revents set to the magic value 0. This magic value causes
aio_dispatch_handler() to invoke ->poll_ready() instead of ->io_read()
for G_IO_IN or ->io_write() for G_IO_OUT.

This magic value 0 hack works for the IOThread where AioHandlers are
placed on ->ready_list and processed by aio_dispatch_ready_handlers().
It does not work for the main loop where all AioHandlers are processed
by aio_dispatch_handlers(), even those that are not ready and have a
revents value of 0.

As a result the main loop invokes ->poll_ready() on AioHandlers that are
not ready. These spurious ->poll_ready() calls waste CPU cycles and
could lead to crashes if the code assumes ->poll() must have succeeded
before ->poll_ready() is called (a reasonable asumption but I haven't
seen it in practice).

Stop using revents to track whether ->poll_ready() will be called on an
AioHandler. Introduce a separate AioHandler->poll_ready field instead.
This eliminates spurious ->poll_ready() calls in the main loop.

Fixes: 826cc32423db2a99d184dbf4f507c737d7e7a4ae ("aio-posix: split poll check from ready handler")
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reported-by: Jason Wang <jasowang@redhat.com>
Tested-by: Jason Wang <jasowang@redhat.com>
Message-id: 20220223155703.136833-1-stefanha@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 util/aio-posix.h |  1 +
 util/aio-posix.c | 32 ++++++++++++++++++--------------
 2 files changed, 19 insertions(+), 14 deletions(-)

diff --git a/util/aio-posix.h b/util/aio-posix.h
index 7f2c37a684..80b927c7f4 100644
--- a/util/aio-posix.h
+++ b/util/aio-posix.h
@@ -37,6 +37,7 @@ struct AioHandler {
     unsigned flags; /* see fdmon-io_uring.c */
 #endif
     int64_t poll_idle_timeout; /* when to stop userspace polling */
+    bool poll_ready; /* has polling detected an event? */
     bool is_external;
 };
 
diff --git a/util/aio-posix.c b/util/aio-posix.c
index 7b9f629218..be0182a3c6 100644
--- a/util/aio-posix.c
+++ b/util/aio-posix.c
@@ -23,15 +23,6 @@
 #include "trace.h"
 #include "aio-posix.h"
 
-/*
- * G_IO_IN and G_IO_OUT are not appropriate revents values for polling, since
- * the handler may not need to access the file descriptor. For example, the
- * handler doesn't need to read from an EventNotifier if it polled a memory
- * location and a read syscall would be slow. Define our own unique revents
- * value to indicate that polling determined this AioHandler is ready.
- */
-#define REVENTS_POLL_READY 0
-
 /* Stop userspace polling on a handler if it isn't active for some time */
 #define POLL_IDLE_INTERVAL_NS (7 * NANOSECONDS_PER_SECOND)
 
@@ -49,6 +40,14 @@ void aio_add_ready_handler(AioHandlerList *ready_list,
     QLIST_INSERT_HEAD(ready_list, node, node_ready);
 }
 
+static void aio_add_poll_ready_handler(AioHandlerList *ready_list,
+                                       AioHandler *node)
+{
+    QLIST_SAFE_REMOVE(node, node_ready); /* remove from nested parent's list */
+    node->poll_ready = true;
+    QLIST_INSERT_HEAD(ready_list, node, node_ready);
+}
+
 static AioHandler *find_aio_handler(AioContext *ctx, int fd)
 {
     AioHandler *node;
@@ -76,6 +75,7 @@ static bool aio_remove_fd_handler(AioContext *ctx, AioHandler *node)
     }
 
     node->pfd.revents = 0;
+    node->poll_ready = false;
 
     /* If the fd monitor has already marked it deleted, leave it alone */
     if (QLIST_IS_INSERTED(node, node_deleted)) {
@@ -247,7 +247,7 @@ static bool poll_set_started(AioContext *ctx, AioHandlerList *ready_list,
 
         /* Poll one last time in case ->io_poll_end() raced with the event */
         if (!started && node->io_poll(node->opaque)) {
-            aio_add_ready_handler(ready_list, node, REVENTS_POLL_READY);
+            aio_add_poll_ready_handler(ready_list, node);
             progress = true;
         }
     }
@@ -282,6 +282,7 @@ bool aio_pending(AioContext *ctx)
     QLIST_FOREACH_RCU(node, &ctx->aio_handlers, node) {
         int revents;
 
+        /* TODO should this check poll ready? */
         revents = node->pfd.revents & node->pfd.events;
         if (revents & (G_IO_IN | G_IO_HUP | G_IO_ERR) && node->io_read &&
             aio_node_check(ctx, node->is_external)) {
@@ -323,11 +324,15 @@ static void aio_free_deleted_handlers(AioContext *ctx)
 static bool aio_dispatch_handler(AioContext *ctx, AioHandler *node)
 {
     bool progress = false;
+    bool poll_ready;
     int revents;
 
     revents = node->pfd.revents & node->pfd.events;
     node->pfd.revents = 0;
 
+    poll_ready = node->poll_ready;
+    node->poll_ready = false;
+
     /*
      * Start polling AioHandlers when they become ready because activity is
      * likely to continue.  Note that starvation is theoretically possible when
@@ -344,7 +349,7 @@ static bool aio_dispatch_handler(AioContext *ctx, AioHandler *node)
         QLIST_INSERT_HEAD(&ctx->poll_aio_handlers, node, node_poll);
     }
     if (!QLIST_IS_INSERTED(node, node_deleted) &&
-        revents == 0 &&
+        poll_ready && revents == 0 &&
         aio_node_check(ctx, node->is_external) &&
         node->io_poll_ready) {
         node->io_poll_ready(node->opaque);
@@ -432,7 +437,7 @@ static bool run_poll_handlers_once(AioContext *ctx,
     QLIST_FOREACH_SAFE(node, &ctx->poll_aio_handlers, node_poll, tmp) {
         if (aio_node_check(ctx, node->is_external) &&
             node->io_poll(node->opaque)) {
-            aio_add_ready_handler(ready_list, node, REVENTS_POLL_READY);
+            aio_add_poll_ready_handler(ready_list, node);
 
             node->poll_idle_timeout = now + POLL_IDLE_INTERVAL_NS;
 
@@ -491,8 +496,7 @@ static bool remove_idle_poll_handlers(AioContext *ctx,
                  * this causes progress.
                  */
                 if (node->io_poll(node->opaque)) {
-                    aio_add_ready_handler(ready_list, node,
-                                          REVENTS_POLL_READY);
+                    aio_add_poll_ready_handler(ready_list, node);
                     progress = true;
                 }
             }
-- 
2.35.1

Re: [PULL for-7.0 1/2] aio-posix: fix build failure io_uring 2.2

[Daniel P. Berrangé]

On Thu, Mar 17, 2022 at 04:57:42PM +0000, Stefan Hajnoczi wrote:
> From: Haiyue Wang <haiyue.wang@intel.com>
> 
> The io_uring fixed "Don't truncate addr fields to 32-bit on 32-bit":
> https://git.kernel.dk/cgit/liburing/commit/?id=d84c29b19ed0b130000619cff40141bb1fc3615b

Ewww, that changes the public ABI of the library on 32-bit
platforms, but failed to bump the soname version, except....

...investigating this I noticed a further change that happend
a few weeks earlier in liburing that actually dropped the
version from the soname entirely making it an unversioned
library.

This is the current shipping 2.1 version:

$ eu-readelf -a liburing.so.2.0.0  | grep SONAME
  SONAME            Library soname: [liburing.so.2]

and in git master:

$ eu-readelf -a src/liburing.so.2.2 | grep SONA
  SONAME            Library soname: [liburing.so]

Surely that's a mistake.

After the ABI incompatibility above, I would have expected
it to bump to liburing.so.3 


> 
> This leads to build failure:
> ../util/fdmon-io_uring.c: In function ‘add_poll_remove_sqe’:
> ../util/fdmon-io_uring.c:182:36: error: passing argument 2 of ‘io_uring_prep_poll_remove’ makes integer from pointer without a cast [-Werror=int-conversion]
>   182 |     io_uring_prep_poll_remove(sqe, node);
>       |                                    ^~~~
>       |                                    |
>       |                                    AioHandler *
> In file included from /root/io/qemu/include/block/aio.h:18,
>                  from ../util/aio-posix.h:20,
>                  from ../util/fdmon-io_uring.c:49:
> /usr/include/liburing.h:415:17: note: expected ‘__u64’ {aka ‘long long unsigned int’} but argument is of type ‘AioHandler *’
>   415 |           __u64 user_data)
>       |           ~~~~~~^~~~~~~~~
> cc1: all warnings being treated as errors
> 
> Use LIBURING_HAVE_DATA64 to check whether the io_uring supports 64-bit
> variants of the get/set userdata, to convert the paramter to the right
> data type.
> 
> Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
> Message-Id: <20220221162401.45415-1-haiyue.wang@intel.com>
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
>  util/fdmon-io_uring.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/util/fdmon-io_uring.c b/util/fdmon-io_uring.c
> index 1461dfa407..ab43052dd7 100644
> --- a/util/fdmon-io_uring.c
> +++ b/util/fdmon-io_uring.c
> @@ -179,7 +179,11 @@ static void add_poll_remove_sqe(AioContext *ctx, AioHandler *node)
>  {
>      struct io_uring_sqe *sqe = get_sqe(ctx);
>  
> +#ifdef LIBURING_HAVE_DATA64
> +    io_uring_prep_poll_remove(sqe, (__u64)(uintptr_t)node);
> +#else
>      io_uring_prep_poll_remove(sqe, node);
> +#endif
>  }
>  
>  /* Add a timeout that self-cancels when another cqe becomes ready */
> -- 
> 2.35.1
> 
> 

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 for-7.0 0/2] Block patches

[Peter Maydell]

On Thu, 17 Mar 2022 at 16:57, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>
> The following changes since commit 1d60bb4b14601e38ed17384277aa4c30c57925d3:
>
>   Merge tag 'pull-request-2022-03-15v2' of https://gitlab.com/thuth/qemu into staging (2022-03-16 10:43:58 +0000)
>
> are available in the Git repository at:
>
>   https://gitlab.com/stefanha/qemu.git tags/block-pull-request
>
> for you to fetch changes up to fc8796465c6cd4091efe6a2f8b353f07324f49c7:
>
>   aio-posix: fix spurious ->poll_ready() callbacks in main loop (2022-03-17 11:23:18 +0000)
>
> ----------------------------------------------------------------
> Pull request
>
> Bug fixes for 7.0.

msys2-32bit CI job fails on test-aio:

| 14/85 ERROR:../tests/unit/test-aio.c:501:test_timer_schedule:
assertion failed: (aio_poll(ctx, true)) ERROR
14/85 qemu:unit / test-aio ERROR 2.40s (exit status 2147483651 or
signal 2147483523 SIGinvalid)

https://gitlab.com/qemu-project/qemu/-/jobs/2217696361

-- PMM

RE: [PULL for-7.0 1/2] aio-posix: fix build failure io_uring 2.2

[Wang, Haiyue]

> -----Original Message-----
> From: Daniel P. Berrangé <berrange@redhat.com>
> Sent: Friday, March 18, 2022 01:14
> To: Stefan Hajnoczi <stefanha@redhat.com>
> Cc: qemu-devel@nongnu.org; Peter Maydell <peter.maydell@linaro.org>; Fam Zheng <fam@euphon.net>; Paolo
> Bonzini <pbonzini@redhat.com>; Wang, Haiyue <haiyue.wang@intel.com>; qemu-block@nongnu.org
> Subject: Re: [PULL for-7.0 1/2] aio-posix: fix build failure io_uring 2.2
> 
> On Thu, Mar 17, 2022 at 04:57:42PM +0000, Stefan Hajnoczi wrote:
> > From: Haiyue Wang <haiyue.wang@intel.com>
> >
> > The io_uring fixed "Don't truncate addr fields to 32-bit on 32-bit":
> > https://git.kernel.dk/cgit/liburing/commit/?id=d84c29b19ed0b130000619cff40141bb1fc3615b
> 
> Ewww, that changes the public ABI of the library on 32-bit
> platforms, but failed to bump the soname version, except....
> 
> ...investigating this I noticed a further change that happend
> a few weeks earlier in liburing that actually dropped the
> version from the soname entirely making it an unversioned
> library.
> 
> This is the current shipping 2.1 version:
> 
> $ eu-readelf -a liburing.so.2.0.0  | grep SONAME
>   SONAME            Library soname: [liburing.so.2]
> 
> and in git master:
> 
> $ eu-readelf -a src/liburing.so.2.2 | grep SONA
>   SONAME            Library soname: [liburing.so]
> 
> Surely that's a mistake.
> 
> After the ABI incompatibility above, I would have expected
> it to bump to liburing.so.3
> 

It's not ABI issue:

https://github.com/axboe/liburing/issues/490

rbernon commented on Dec 5, 2021
Well the documentation says that, io_uring_prep_timeout_update, io_uring_prep_timeout_remove,
io_uring_prep_poll_update, io_uring_prep_poll_remove, io_uring_prep_cancel, all target a previously
submitted sqe with a matching user_data, but they all take a void * to match it, which isn't correct
as the match is going to happen on the 64bit value.

The previously submitted sqe user_data may be any 64bit value, including on 32bit as the submitter
may have set the value itself, without going through the io_uring_sqe_set_data helpers. For instance
if you only need an index (or fd) and operation type, which fit well on 64bits, you don't really want
to use a pointer there.

> 
> >
> > This leads to build failure:
> > ../util/fdmon-io_uring.c: In function ‘add_poll_remove_sqe’:
> > ../util/fdmon-io_uring.c:182:36: error: passing argument 2 of ‘io_uring_prep_poll_remove’ makes
> integer from pointer without a cast [-Werror=int-conversion]
> >   182 |     io_uring_prep_poll_remove(sqe, node);
> >       |                                    ^~~~
> >       |                                    |
> >       |                                    AioHandler *
> > In file included from /root/io/qemu/include/block/aio.h:18,
> >                  from ../util/aio-posix.h:20,
> >                  from ../util/fdmon-io_uring.c:49:
> > /usr/include/liburing.h:415:17: note: expected ‘__u64’ {aka ‘long long unsigned int’} but argument
> is of type ‘AioHandler *’
> >   415 |           __u64 user_data)
> >       |           ~~~~~~^~~~~~~~~
> > cc1: all warnings being treated as errors
> >
> > Use LIBURING_HAVE_DATA64 to check whether the io_uring supports 64-bit
> > variants of the get/set userdata, to convert the paramter to the right
> > data type.
> >
> > Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
> > Message-Id: <20220221162401.45415-1-haiyue.wang@intel.com>
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > ---
> >  util/fdmon-io_uring.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/util/fdmon-io_uring.c b/util/fdmon-io_uring.c
> > index 1461dfa407..ab43052dd7 100644
> > --- a/util/fdmon-io_uring.c
> > +++ b/util/fdmon-io_uring.c
> > @@ -179,7 +179,11 @@ static void add_poll_remove_sqe(AioContext *ctx, AioHandler *node)
> >  {
> >      struct io_uring_sqe *sqe = get_sqe(ctx);
> >
> > +#ifdef LIBURING_HAVE_DATA64
> > +    io_uring_prep_poll_remove(sqe, (__u64)(uintptr_t)node);
> > +#else
> >      io_uring_prep_poll_remove(sqe, node);
> > +#endif
> >  }
> >
> >  /* Add a timeout that self-cancels when another cqe becomes ready */
> > --
> > 2.35.1
> >
> >
> 
> 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 for-7.0 1/2] aio-posix: fix build failure io_uring 2.2

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1183 bytes --]

On Thu, Mar 17, 2022 at 05:14:20PM +0000, Daniel P. Berrangé wrote:
> On Thu, Mar 17, 2022 at 04:57:42PM +0000, Stefan Hajnoczi wrote:
> > From: Haiyue Wang <haiyue.wang@intel.com>
> > 
> > The io_uring fixed "Don't truncate addr fields to 32-bit on 32-bit":
> > https://git.kernel.dk/cgit/liburing/commit/?id=d84c29b19ed0b130000619cff40141bb1fc3615b
> 
> Ewww, that changes the public ABI of the library on 32-bit
> platforms, but failed to bump the soname version, except....
> 
> ...investigating this I noticed a further change that happend
> a few weeks earlier in liburing that actually dropped the
> version from the soname entirely making it an unversioned
> library.
> 
> This is the current shipping 2.1 version:
> 
> $ eu-readelf -a liburing.so.2.0.0  | grep SONAME
>   SONAME            Library soname: [liburing.so.2]
> 
> and in git master:
> 
> $ eu-readelf -a src/liburing.so.2.2 | grep SONA
>   SONAME            Library soname: [liburing.so]
> 
> Surely that's a mistake.
> 
> After the ABI incompatibility above, I would have expected
> it to bump to liburing.so.3 

Thanks, I have sent a liburing patch to fix the soname.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PULL for-7.0 0/2] Block patches

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]

On Thu, Mar 17, 2022 at 06:36:36PM +0000, Peter Maydell wrote:
> On Thu, 17 Mar 2022 at 16:57, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> >
> > The following changes since commit 1d60bb4b14601e38ed17384277aa4c30c57925d3:
> >
> >   Merge tag 'pull-request-2022-03-15v2' of https://gitlab.com/thuth/qemu into staging (2022-03-16 10:43:58 +0000)
> >
> > are available in the Git repository at:
> >
> >   https://gitlab.com/stefanha/qemu.git tags/block-pull-request
> >
> > for you to fetch changes up to fc8796465c6cd4091efe6a2f8b353f07324f49c7:
> >
> >   aio-posix: fix spurious ->poll_ready() callbacks in main loop (2022-03-17 11:23:18 +0000)
> >
> > ----------------------------------------------------------------
> > Pull request
> >
> > Bug fixes for 7.0.
> 
> msys2-32bit CI job fails on test-aio:
> 
> | 14/85 ERROR:../tests/unit/test-aio.c:501:test_timer_schedule:
> assertion failed: (aio_poll(ctx, true)) ERROR
> 14/85 qemu:unit / test-aio ERROR 2.40s (exit status 2147483651 or
> signal 2147483523 SIGinvalid)
> 
> https://gitlab.com/qemu-project/qemu/-/jobs/2217696361

Looks like a random failure. The commits touch Linux/POSIX code so I
don't know how this pull request could affect Windows.

I reran and the test passed:
https://gitlab.com/qemu-project/qemu/-/jobs/2229158826

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PULL for-7.0 0/2] Block patches

[Peter Maydell]

On Mon, 21 Mar 2022 at 14:44, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>
> On Thu, Mar 17, 2022 at 06:36:36PM +0000, Peter Maydell wrote:
> > On Thu, 17 Mar 2022 at 16:57, Stefan Hajnoczi <stefanha@redhat.com> wrote:
> > >
> > > The following changes since commit 1d60bb4b14601e38ed17384277aa4c30c57925d3:
> > >
> > >   Merge tag 'pull-request-2022-03-15v2' of https://gitlab.com/thuth/qemu into staging (2022-03-16 10:43:58 +0000)
> > >
> > > are available in the Git repository at:
> > >
> > >   https://gitlab.com/stefanha/qemu.git tags/block-pull-request
> > >
> > > for you to fetch changes up to fc8796465c6cd4091efe6a2f8b353f07324f49c7:
> > >
> > >   aio-posix: fix spurious ->poll_ready() callbacks in main loop (2022-03-17 11:23:18 +0000)
> > >
> > > ----------------------------------------------------------------
> > > Pull request
> > >
> > > Bug fixes for 7.0.
> >
> > msys2-32bit CI job fails on test-aio:
> >
> > | 14/85 ERROR:../tests/unit/test-aio.c:501:test_timer_schedule:
> > assertion failed: (aio_poll(ctx, true)) ERROR
> > 14/85 qemu:unit / test-aio ERROR 2.40s (exit status 2147483651 or
> > signal 2147483523 SIGinvalid)
> >
> > https://gitlab.com/qemu-project/qemu/-/jobs/2217696361
>
> Looks like a random failure. The commits touch Linux/POSIX code so I
> don't know how this pull request could affect Windows.

Seems like it.


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/7.0
for any user-visible changes.

-- PMM

[PULL for-7.0 0/2] Block patches

[Stefan Hajnoczi]

The following changes since commit 15ef89d2a1a7b93845a6b09c2ee8e1979f6eb30b:

  Update version for v7.0.0-rc1 release (2022-03-22 22:58:44 +0000)

are available in the Git repository at:

  https://gitlab.com/stefanha/qemu.git tags/block-pull-request

for you to fetch changes up to 2539eade4f689eda7e9fe45486f18334bfbafaf0:

  hw: Fix misleading hexadecimal format (2022-03-24 10:38:42 +0000)

----------------------------------------------------------------
Pull request

Philippe found cases where the 0x%d format string was used, leading to
misleading output. The patches look harmless and could save people time, so I
think it's worth including them in 7.0.

----------------------------------------------------------------

Philippe Mathieu-Daudé (2):
  block: Fix misleading hexadecimal format
  hw: Fix misleading hexadecimal format

 block/parallels-ext.c | 2 +-
 hw/i386/sgx.c         | 2 +-
 hw/i386/trace-events  | 6 +++---
 hw/misc/trace-events  | 4 ++--
 hw/scsi/trace-events  | 4 ++--
 5 files changed, 9 insertions(+), 9 deletions(-)

-- 
2.35.1

Re: [PULL for-7.0 0/2] Block patches

[Peter Maydell]

On Thu, 24 Mar 2022 at 17:15, Stefan Hajnoczi <stefanha@redhat.com> wrote:
>
> The following changes since commit 15ef89d2a1a7b93845a6b09c2ee8e1979f6eb30b:
>
>   Update version for v7.0.0-rc1 release (2022-03-22 22:58:44 +0000)
>
> are available in the Git repository at:
>
>   https://gitlab.com/stefanha/qemu.git tags/block-pull-request
>
> for you to fetch changes up to 2539eade4f689eda7e9fe45486f18334bfbafaf0:
>
>   hw: Fix misleading hexadecimal format (2022-03-24 10:38:42 +0000)
>
> ----------------------------------------------------------------
> Pull request
>
> Philippe found cases where the 0x%d format string was used, leading to
> misleading output. The patches look harmless and could save people time, so I
> think it's worth including them in 7.0.
>


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/7.0
for any user-visible changes.

-- PMM