All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: jasowang@redhat.com,  mst@redhat.com,  peterx@redhat.com,
	farosas@suse.de,  raphael.s.norwitz@gmail.com,
	 bchaney@akamai.com, qemu-devel@nongnu.org,  berrange@redhat.com,
	 pbonzini@redhat.com, yc-core@yandex-team.ru,
	 mark.caveayland@nutanix.com,  Jason Wang <jasowangio@gmail.com>,
	 Eric Blake <eblake@redhat.com>
Subject: Re: [PATCH v21 15/16] net/tap: support local migration with virtio-net
Date: Thu, 20 Aug 2026 11:16:45 +0200	[thread overview]
Message-ID: <87cxvd2ltu.fsf@pond.sub.org> (raw)
In-Reply-To: <20260819180201.1970193-16-vsementsov@yandex-team.ru> (Vladimir Sementsov-Ogievskiy's message of "Wed, 19 Aug 2026 21:01:58 +0300")

Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> writes:

> Support transferring of TAP state (including open fd).
>
> Add new property "x-permit-local-migration", which defines whether
> local migration is actually permitted for this TAP device.
>
> Note that local-migration is enabled by global "local" migration
> parameter, but individual devices may have additional options to
> enable/disable it per device.
>
> The tricky thing is that we need to know whether to call open/connect in
> TAP initialization code, i.e. we need to know the value of migration
> parameter "local" when creating the TAP device.  For incoming migration,
> we can know only for TAP devices created with QMP after setting the
> migration parameter with QMP.
>
> So the full picture is:
>
> On source, to start outgoing "local" migration you need:
>
>  - migration parameter "local" set to true
>  - "x-permit-local-migration" TAP option set to true
>
> If at least one of these options is not set, TAP backend
> doesn't participate in migration.
>
> On target, things are more difficult:
>
> Same, you need both "local" and "x-permit-local-migration"
> be set. And same, if one of them is not set, TAP backend
> is initialized as usual, and doesn't accept any incoming
> state.
>
> Additionally, if you are going to set "local", it must be
> set before creating the TAP device. If TAP device created
> with "local" unset, it initializes as usual. If you enable
> "local" after it and start incoming migration, it will fail
> in .pre_load handler of TAP backend.
>
> Moreover, there are interface restrictions: if you create TAP
> device when QEMU is in INCOMING state, and both "local"
> and "x-permit-local-migration" set, most of TAP options are
> not allowed, and script/downscript are required to be explicitly
> disabled.
>
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
> Reviewed-by: Ben Chaney <bchaney@akamai.com>

QAPI schema
Acked-by: Markus Armbruster <armbru@redhat.com>



  reply	other threads:[~2026-08-20  9:17 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260819180201.1970193-1-vsementsov@yandex-team.ru>
2026-08-19 18:01 ` [PATCH v21 01/16] net/tap: rework tap_parse_script Vladimir Sementsov-Ogievskiy
2026-08-19 18:01 ` [PATCH v21 02/16] net/tap: improve script/downscript options documentation Vladimir Sementsov-Ogievskiy
2026-08-19 18:01 ` [PATCH v21 03/16] net/tap: deprecate "no" as special value for script/downscript Vladimir Sementsov-Ogievskiy
2026-08-19 18:01 ` [PATCH v21 05/16] net/tap: move vhost initialization to tap_setup_vhost() Vladimir Sementsov-Ogievskiy
2026-08-19 18:01 ` [PATCH v21 06/16] net/tap: use container_of instead of DO_UPCAST Vladimir Sementsov-Ogievskiy
2026-08-19 18:01 ` [PATCH v21 07/16] net/tap: QOMify tap backend Vladimir Sementsov-Ogievskiy
2026-08-19 18:01 ` [PATCH v21 10/16] migration/fd: fix fd leak when fd is not valid for migration Vladimir Sementsov-Ogievskiy
2026-08-19 18:53   ` Peter Xu
2026-08-19 18:01 ` [PATCH v21 11/16] migration/fd: add errp parameter to migration_fd_valid() Vladimir Sementsov-Ogievskiy
2026-08-19 18:54   ` Peter Xu
2026-08-19 18:01 ` [PATCH v21 12/16] migration: check that transfer is UNIX socket when "local" set Vladimir Sementsov-Ogievskiy
2026-08-19 18:59   ` Peter Xu
2026-08-19 18:01 ` [PATCH v21 13/16] virtio-net: support local migration of backend Vladimir Sementsov-Ogievskiy
2026-08-19 18:01 ` [PATCH v21 15/16] net/tap: support local migration with virtio-net Vladimir Sementsov-Ogievskiy
2026-08-20  9:16   ` Markus Armbruster [this message]
2026-08-19 18:01 ` [PATCH v21 16/16] tests/functional: add test_tap_migration Vladimir Sementsov-Ogievskiy
2026-08-27 11:39 ` [PATCH v21 00/16] virtio-net: live-TAP local migration Vladimir Sementsov-Ogievskiy

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=87cxvd2ltu.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=bchaney@akamai.com \
    --cc=berrange@redhat.com \
    --cc=eblake@redhat.com \
    --cc=farosas@suse.de \
    --cc=jasowang@redhat.com \
    --cc=jasowangio@gmail.com \
    --cc=mark.caveayland@nutanix.com \
    --cc=mst@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=raphael.s.norwitz@gmail.com \
    --cc=vsementsov@yandex-team.ru \
    --cc=yc-core@yandex-team.ru \
    /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.