From: Peter Xu <peterx@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: Fabiano Rosas <farosas@suse.de>,
qemu-devel@nongnu.org, Eric Blake <eblake@redhat.com>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [RFC PATCH v3 3/3] migration: Add fd to FileMigrationArgs
Date: Fri, 15 Mar 2024 12:05:22 -0400 [thread overview]
Message-ID: <ZfRxwml7m0DQVO2b@x1n> (raw)
In-Reply-To: <ZfQNDv--4BnN5zYx@redhat.com>
[I queued patch 1-2 into -stable, leaving this patch for further
discussions]
On Fri, Mar 15, 2024 at 08:55:42AM +0000, Daniel P. Berrangé wrote:
> The 'file:' protocol eventually calls into qemu_open, and this
> transparently allows for FD passing using /dev/fdset/NNN syntax
> to pass in FDs.
If it always use /dev/fdsets for files, does it mean that the newly added
SOCKET_ADDRESS_TYPE_FD support on mapped-ram will never be used (so we can
drop them)?
What about the old getfd? Is it obsolete because it relies on monitor
object? Or maybe it's still in use?
It would be greatly helpful if there can be a summary of how libvirt uses
fd for migration purpose.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2024-03-15 16:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-15 3:20 [PATCH v3 0/3] migration mapped-ram fixes Fabiano Rosas
2024-03-15 3:20 ` [PATCH v3 1/3] migration/multifd: Ensure we're not given a socket for file migration Fabiano Rosas
2024-03-15 11:38 ` Peter Xu
2024-03-15 3:20 ` [PATCH v3 2/3] migration/multifd: Duplicate the fd for the outgoing_args Fabiano Rosas
2024-03-15 11:39 ` Peter Xu
2024-03-15 3:20 ` [RFC PATCH v3 3/3] migration: Add fd to FileMigrationArgs Fabiano Rosas
2024-03-15 8:55 ` Daniel P. Berrangé
2024-03-15 12:13 ` Fabiano Rosas
2024-03-19 16:31 ` Daniel P. Berrangé
2024-03-15 16:05 ` Peter Xu [this message]
2024-03-15 18:01 ` Fabiano Rosas
2024-03-15 20:54 ` Peter Xu
2024-03-19 16:25 ` Daniel P. Berrangé
2024-03-19 19:25 ` Peter Xu
2024-03-19 19:52 ` Daniel P. Berrangé
2024-03-19 20:15 ` Peter Xu
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=ZfRxwml7m0DQVO2b@x1n \
--to=peterx@redhat.com \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=eblake@redhat.com \
--cc=farosas@suse.de \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).