We already do that for any FD, coming from qio-channel
(except when QIO_CHANNEL_READ_FLAG_FD_PRESERVE_BLOCKING is set,
see qio_channel_handle_fds()), and therefore for all FDs coming
from qmp add-fd command.

Let -add-fd option behave the same way.

This fixes at least several places, where code is unprepared
to non-blocking FDs:

- util/oslib-posix.c: qemu_write_pidfile()

Uses qemu_write_full(), unprepared to non-blocking.

- hw/uefi/var-service-json.c: uefi_vars_json_init()

Use write() and don't handle EAGAIN: unprepared for non-blocking.

- dump/dump.c: qmp_dump_guest_memory()

Use qemu_write_full() - unprepared

- chardev/char.c: logfd

Use qemu_write_full() - unprepared

- block/file-posix.c: raw_co_create()

May use write() and not handle EAGAIN during raw_regular_truncate() -
unprepared.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
---

Hi all.

That's as an answer to Daniel's comment at

  Re: [PATCH v3 1/3] char: qemu_chr_write_log() use qemu_write_full()
  https://lore.kernel.org/qemu-devel/aZ8csNV0DAHxK7uh@redhat.com/

Marked as RFC, because that may be considered a breaking change, I'm
not sure should we care about it here.

If the patch is OK, and we want it, add

  Suggested-by: Daniel P. Berrangé <berrange@redhat.com>

tag.

 system/vl.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/system/vl.c b/system/vl.c
index 3e341142a0c..edfdd4051f1 100644
--- a/system/vl.c
+++ b/system/vl.c
@@ -622,6 +622,10 @@ static int parse_add_fd(void *opaque, QemuOpts *opts, Error **errp)
         return -1;
     }
 
+    if (!qemu_set_blocking(dupfd, true, errp)) {
+        return -1;
+    }
+
     /* add the duplicate fd, and optionally the opaque string, to the fd set */
     fdinfo = monitor_fdset_add_fd(dupfd, true, fdset_id, fd_opaque,
                                   &error_abort);
-- 
2.52.0