From: "manish.mishra" <manish.mishra@nutanix.com>
To: qemu-devel@nongnu.org
Cc: berrange@redhat.com, peterx@redhat.com,
prerna.saxena@nutanix.com, quintela@redhat.com,
dgilbert@redhat.com, lsoaresp@redhat.com,
"manish.mishra" <manish.mishra@nutanix.com>
Subject: [PATCH v5 0/2] check magic value for deciding the mapping of channels
Date: Wed, 23 Nov 2022 17:27:33 +0000 [thread overview]
Message-ID: <20221123172735.25181-1-manish.mishra@nutanix.com> (raw)
Current logic assumes that channel connections on the destination side are
always established in the same order as the source and the first one will
always be the main channel followed by the multifid or post-copy
preemption channel. This may not be always true, as even if a channel has a
connection established on the source side it can be in the pending state on
the destination side and a newer connection can be established first.
Basically causing out of order mapping of channels on the destination side.
Currently, all channels except post-copy preempt send a magic number, this
patch uses that magic number to decide the type of channel. This logic is
applicable only for precopy(multifd) live migration, as mentioned, the
post-copy preempt channel does not send any magic number. Also, tls live
migrations already does tls handshake before creating other channels, so
this issue is not possible with tls, hence this logic is avoided for tls
live migrations. This patch uses MSG_PEEK to check the magic number of
channels so that current data/control stream management remains
un-effected.
v2:
TLS does not support MSG_PEEK, so V1 was broken for tls live
migrations. For tls live migration, while initializing main channel
tls handshake is done before we can create other channels, so this
issue is not possible for tls live migrations. In V2 added a check
to avoid checking magic number for tls live migration and fallback
to older method to decide mapping of channels on destination side.
v3:
1. Split change in two patches, io patch for read_peek routines,
migration patch for migration related changes.
2. Add flags to io_readv calls to get extra read flags like
MSG_PEEK.
3. Some other minor fixes.
v4:
1. Removed common *all_eof routines for read peek and added one
specific to live migration.
2. Updated to use qemu_co_sleep_ns instead of qio_channel_yield.
3. Some other minor fixes.
v5:
1. Handle busy-wait in migration_channel_read_peek due partial reads.
manish.mishra (2):
io: Add support for MSG_PEEK for socket channel
migration: check magic value for deciding the mapping of channels
chardev/char-socket.c | 4 +--
include/io/channel.h | 6 ++++
io/channel-buffer.c | 1 +
io/channel-command.c | 1 +
io/channel-file.c | 1 +
io/channel-null.c | 1 +
io/channel-socket.c | 17 ++++++++++-
io/channel-tls.c | 1 +
io/channel-websock.c | 1 +
io/channel.c | 16 +++++++---
migration/channel-block.c | 1 +
migration/channel.c | 45 +++++++++++++++++++++++++++++
migration/channel.h | 5 ++++
migration/migration.c | 45 +++++++++++++++++++++--------
migration/multifd.c | 12 +++-----
migration/multifd.h | 2 +-
migration/postcopy-ram.c | 5 +---
migration/postcopy-ram.h | 2 +-
scsi/qemu-pr-helper.c | 2 +-
tests/qtest/tpm-emu.c | 2 +-
tests/unit/test-io-channel-socket.c | 1 +
util/vhost-user-server.c | 2 +-
22 files changed, 137 insertions(+), 36 deletions(-)
--
2.22.3
next reply other threads:[~2022-11-23 17:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-23 17:27 manish.mishra [this message]
2022-11-23 17:27 ` [PATCH v5 1/2] io: Add support for MSG_PEEK for socket channel manish.mishra
2022-11-23 18:04 ` Peter Xu
2022-11-29 10:54 ` manish.mishra
2022-11-29 14:27 ` Peter Xu
2022-11-29 14:38 ` manish.mishra
2022-12-13 20:37 ` Peter Xu
2022-11-23 17:27 ` [PATCH v5 2/2] migration: check magic value for deciding the mapping of channels manish.mishra
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=20221123172735.25181-1-manish.mishra@nutanix.com \
--to=manish.mishra@nutanix.com \
--cc=berrange@redhat.com \
--cc=dgilbert@redhat.com \
--cc=lsoaresp@redhat.com \
--cc=peterx@redhat.com \
--cc=prerna.saxena@nutanix.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.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.