In the early days of io_uring it was possible for io_uring_setup(2) to
fail due to exhausting RLIMIT_MEMLOCK. QEMU's solution was to fall back
to epoll(7) or ppoll(2) when io_uring could not be used in an
AioContext.

Nowadays io_uring memory is accounted differently so io_uring_setup(2)
won't fail. Treat failure as a fatal error. Keep it simple: io_uring is
available if and only if CONFIG_LINUX_IO_URING is defined.

Upcoming features that rely on io_uring won't need to handle the case
where a subset of AioContexts lacks io_uring. This will simplify the
aio_add_sqe() API introduced in the next commit.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 util/fdmon-io_uring.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/util/fdmon-io_uring.c b/util/fdmon-io_uring.c
index 2092d08d24..18b33a0370 100644
--- a/util/fdmon-io_uring.c
+++ b/util/fdmon-io_uring.c
@@ -45,6 +45,7 @@
 
 #include "qemu/osdep.h"
 #include <poll.h>
+#include "qemu/error-report.h"
 #include "qemu/rcu_queue.h"
 #include "aio-posix.h"
 
@@ -369,7 +370,8 @@ bool fdmon_io_uring_setup(AioContext *ctx)
 
     ret = io_uring_queue_init(FDMON_IO_URING_ENTRIES, &ctx->fdmon_io_uring, 0);
     if (ret != 0) {
-        return false;
+        error_report("failed to initialize io_uring: %s", strerror(-ret));
+        exit(EXIT_FAILURE);
     }
 
     QSLIST_INIT(&ctx->submit_list);
-- 
2.49.0

Am 01.04.2025 um 16:27 hat Stefan Hajnoczi geschrieben:
> In the early days of io_uring it was possible for io_uring_setup(2) to
> fail due to exhausting RLIMIT_MEMLOCK. QEMU's solution was to fall back
> to epoll(7) or ppoll(2) when io_uring could not be used in an
> AioContext.
> 
> Nowadays io_uring memory is accounted differently so io_uring_setup(2)
> won't fail. Treat failure as a fatal error. Keep it simple: io_uring is
> available if and only if CONFIG_LINUX_IO_URING is defined.
> 
> Upcoming features that rely on io_uring won't need to handle the case
> where a subset of AioContexts lacks io_uring. This will simplify the
> aio_add_sqe() API introduced in the next commit.
> 
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>

While making failure to set up io_uring for an AioContext a hard error
feels fine to me, I feel a bit uneasy about having fatal errors like
this in functions that aren't only called during startup. This function
is also called when adding an iothread object at runtime. The failure
mode that I would expect there is that object-add returns an error, not
that the whole QEMU process exits.

Kevin

On Fri, Apr 25, 2025 at 05:51:43PM +0200, Kevin Wolf wrote:
> Am 01.04.2025 um 16:27 hat Stefan Hajnoczi geschrieben:
> > In the early days of io_uring it was possible for io_uring_setup(2) to
> > fail due to exhausting RLIMIT_MEMLOCK. QEMU's solution was to fall back
> > to epoll(7) or ppoll(2) when io_uring could not be used in an
> > AioContext.
> > 
> > Nowadays io_uring memory is accounted differently so io_uring_setup(2)
> > won't fail. Treat failure as a fatal error. Keep it simple: io_uring is
> > available if and only if CONFIG_LINUX_IO_URING is defined.
> > 
> > Upcoming features that rely on io_uring won't need to handle the case
> > where a subset of AioContexts lacks io_uring. This will simplify the
> > aio_add_sqe() API introduced in the next commit.
> > 
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> 
> While making failure to set up io_uring for an AioContext a hard error
> feels fine to me, I feel a bit uneasy about having fatal errors like
> this in functions that aren't only called during startup. This function
> is also called when adding an iothread object at runtime. The failure
> mode that I would expect there is that object-add returns an error, not
> that the whole QEMU process exits.

Thanks for bringing this up. I'll fix it in the next revision.

Stefan