On 02.11.25 14:39, Marc-André Lureau wrote:
Hi
On Fri, Oct 31, 2025 at 7:59 PM Vladimir Sementsov-Ogievskiy <[email protected]
<mailto:[email protected]>> wrote:
For further vhost-user-blk backend-transfer migration realization we
want to give it (vhost-user-blk) a possibility (and responsibility) to
decide when do connect.
For incoming migration we'll need to postpone connect at least until
early stage of migrate-incoming command, when we already know all
migration parameters and can decide, are we going to do incoming
backend-transfer (and get chardev fd from incoming stream), or we
finally need to connect.
Signed-off-by: Vladimir Sementsov-Ogievskiy <[email protected]
<mailto:[email protected]>>
---
chardev/char-fe.c | 32 ++++++++++++++++++++++++-----
hw/core/qdev-properties-system.c | 26 ++++++++++++++++++++---
include/chardev/char-fe.h | 8 ++++++--
include/hw/qdev-properties-system.h | 3 +++
4 files changed, 59 insertions(+), 10 deletions(-)
diff --git a/chardev/char-fe.c b/chardev/char-fe.c
index c67b4d640f..1132ec0501 100644
--- a/chardev/char-fe.c
+++ b/chardev/char-fe.c
@@ -189,15 +189,26 @@ bool qemu_chr_fe_backend_open(CharFrontend *c)
return c->chr && c->chr->be_open;
}
-bool qemu_chr_fe_init(CharFrontend *c, Chardev *s, Error **errp)
+bool qemu_chr_fe_init_ex(CharFrontend *c, Chardev *s, bool connect,
+ Error **errp)
{
unsigned int tag = 0;
- if (!qemu_chr_connect(s, errp)) {
- return false;
- }
-
if (s) {
+ if (connect) {
+ if (!qemu_chr_connect(s, errp)) {
+ return false;
+ }
+ } else {
+ /* DEFINE_PROP_CHR_NO_CONNECT */
+ if (!s->connect_postponed) {
+ error_setg(errp,
+ "Chardev %s does not support postponed connect",
+ s->label);
+ return false;
+ }
+ }
+
if (CHARDEV_IS_MUX(s)) {
MuxChardev *d = MUX_CHARDEV(s);
@@ -210,6 +221,12 @@ bool qemu_chr_fe_init(CharFrontend *c, Chardev *s,
Error **errp)
} else {
s->fe = c;
}
+ } else {
+ /*
+ * connect=false comes only from DEFINE_PROP_CHR_NO_CONNECT,
+ * through do_set_chr, which provides chardev ptr.
+ */
+ assert(connect);
Is this useful to assert?
Hmm. I started to write "yes, because, if in future we introduce code path,
which will
somehow pass s=NULL and connect=false, we'll do a wrong thing.."
But looking more closely at semantics of s=0, looks like connect could be just
ignored:
no backend, nothing to connect.. So connect=true with s=0 looks maybe more wrong
than connect=false.
I'll drop the assertion, and add not into qemu_chr_fe_init_ex(), that @connect
is ignored
for s=NULL case.
--
Best regards,
Vladimir
