All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Steven Sistare <steven.sistare@oracle.com>
Cc: JAEHOON KIM <jhkim@linux.ibm.com>,
	qemu-devel@nongnu.org, jjherne@linux.ibm.com, peterx@redhat.com,
	farosas@suse.de
Subject: Re: [PATCH v1] migration: Wait for cpr.sock file to appear before connecting
Date: Mon, 9 Jun 2025 14:20:56 +0100	[thread overview]
Message-ID: <aEbfuM681MJh2S-b@redhat.com> (raw)
In-Reply-To: <f46393bb-115a-489f-aa8d-08348e89d25e@oracle.com>

On Mon, Jun 09, 2025 at 09:12:27AM -0400, Steven Sistare wrote:
> On 6/9/2025 4:06 AM, Daniel P. Berrangé wrote:
> > On Fri, Jun 06, 2025 at 03:37:56PM -0400, Steven Sistare wrote:
> > > 
> > > The easiest solution, with no interface changes, is adding wait_for_socket() in qtest,
> > > with this addition from Daniel:
> > > 
> > >    "With the busy wait you risk looping forever if the child (target) QEMU
> > >    already exited for some reason without ever creating the socket. You
> > >    can mitigate this by using 'kill($PID, 0)' in the loop and looking
> > >    for -ERSCH, but this only works if you know the pid involved."
> > > 
> > > Daniel also suggested:
> > >    "For the tests, passing a pre-opened UNIX socket FD could work"
> > > 
> > > Note we can not use any of the standard chardev options to specify such a socket,
> > > because the cpr socket is created before chardevs are created.
> > > 
> > > Perhaps we could specify the fd in an extension of the MigrationChannel MigrationAddress.
> > > { 'union': 'MigrationAddress',
> > >    'base': { 'transport' : 'MigrationAddressType'},
> > >    'discriminator': 'transport',
> > >    'data': {
> > >      'socket': 'SocketAddress',
> > >      'exec': 'MigrationExecCommand',
> > >      'rdma': 'InetSocketAddress',
> > >      'file': 'FileMigrationArgs',
> > >      'fd':   'FdMigrationArgs' } }           <-- add this
> > > 
> > > That would be useful for all clients, but this is asking a lot from you,
> > > when you are just trying to fix the tests.
> > 
> > Note, 'SocketAddress' already has an option for declaring a FD that
> > represents a socket.
> 
> Yes, but if I understand, you proposed passing an fd that represents a
> pre-listened socket, which requires target qemu to accept() first.  The
> existing FdSocketAddress is ready to read.  We could add a boolean to enable
> the new behavior.

It can do both actually - it depends on what APIs the QEMU uses the
SocketAddress with.

If it is used with qio_channel_socket_connect* the FD must be an
active peer connection.

If it is used with qio_channel_socket_listen*/qio_net_listener* the
FD must be listener socket.

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 :|



  reply	other threads:[~2025-06-09 13:21 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-05 23:08 [PATCH v1] migration: Wait for cpr.sock file to appear before connecting Jaehoon Kim
2025-06-06 13:40 ` Fabiano Rosas
2025-06-06 14:48   ` JAEHOON KIM
2025-06-06 15:47     ` Daniel P. Berrangé
2025-06-06 13:53 ` Daniel P. Berrangé
2025-06-06 14:14   ` Steven Sistare
2025-06-06 15:06     ` JAEHOON KIM
2025-06-06 15:12       ` Steven Sistare
2025-06-06 15:37         ` JAEHOON KIM
2025-06-06 15:43           ` Daniel P. Berrangé
2025-06-06 15:50             ` Steven Sistare
2025-06-06 16:06               ` Daniel P. Berrangé
2025-06-06 17:04                 ` Steven Sistare
2025-06-06 18:06                   ` JAEHOON KIM
2025-06-06 19:37                     ` Steven Sistare
2025-06-08 22:01                       ` JAEHOON KIM
2025-06-09  8:06                       ` Daniel P. Berrangé
2025-06-09 13:12                         ` Steven Sistare
2025-06-09 13:20                           ` Daniel P. Berrangé [this message]
2025-06-09 13:39                             ` Steven Sistare
2025-06-09 13:48                               ` JAEHOON KIM
2025-06-09 13:50                               ` Daniel P. Berrangé
2025-06-09 14:54                                 ` JAEHOON KIM
2025-06-09 14:57                                   ` Daniel P. Berrangé
2025-06-09 15:32                                     ` JAEHOON KIM

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aEbfuM681MJh2S-b@redhat.com \
    --to=berrange@redhat.com \
    --cc=farosas@suse.de \
    --cc=jhkim@linux.ibm.com \
    --cc=jjherne@linux.ibm.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=steven.sistare@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.