Hi all!

Here is a new migration parameter backend-transfer, which allows to
enable local migration of TAP virtio-net backend (and maybe other
devices and backends in future), including its properties and open
fds.

With this new option, management software doesn't need to initialize
new TAP and do a switch to it. Nothing should be done around
virtio-net in local migration: it just migrates and continues to use
same TAP device. So we avoid extra logic in management software, extra
allocations in kernel (for new TAP), and corresponding extra delay in
migration downtime.

v10:

reworked interface:

1. backend-transfer migration parameter - simple boolean

2. backend-transfer option for virtio-net device - in combination with
[1] it enables the feature for concrete virtio-net device

3. incoming-fds option for TAP - to skip any open() calls and setting
up the fd, and instead wait for incoming FD.

Why we need [1]? To be able to simply choose between local and remote
migration, not touching device options.

Why we need [2]? Because otherwise we have to significantly complicate
migration paremeter (to be a list of QOM paths of devices to enable
backend-transfer for), which doesn't look good architectural design
(we don't want to end with migration parameters like

feature1 = [list of QOM paths],
feature2 = [list of QOM paths]k,
...

Why we need [3]? To avoid complicated logic of postponing the whole
initialization of TAP up to pre-incoming point (see
"[PATCH v9 0/9] net/tap: postpone connect"), and to make the whole
feature more reliable: with such a parameter user is sure, that
backend code will not do any open()/connect(), etc, which may
influence running source vm. Automatic logic of 3 stage postponing
in v9 (first, we postpone initialization up to attaching to frontend,
then, if it's a virtio-net, it take ownership and postpone initializing
of backend up to pre-incoming point (where we know migration
parameters), and finally if it's a backend-transfer, postpone it up
to post-load) can't be so reliable. Misconfiguration on target may
lead to breaking source vm. And with separate parameter, everything
becomes a lot simpler and reliable.


The series is based on
"[PATCH v2 00/12] net: refactoring and fixes"
Based-on: <20260129213215.1405459-1-vsementsov@yandex-team.ru>

Vladimir Sementsov-Ogievskiy (8):
  net/tap: move vhost-net open() calls to tap_parse_vhost_fds()
  net/tap: move vhost initialization to tap_setup_vhost()
  qapi: add backend-transfer migration parameter
  net: introduce vmstate_net_peer_backend
  virtio-net: support backend-transfer migration
  net/tap: support backend-transfer migration
  tests/functional: add skipWithoutSudo() decorator
  tests/functional: add test_tap_migration

 hw/core/machine.c                             |   4 +-
 hw/net/virtio-net.c                           | 137 +++++-
 include/hw/virtio/virtio-net.h                |   2 +
 include/migration/misc.h                      |   2 +
 include/net/net.h                             |   6 +
 migration/options.c                           |  18 +-
 net/net.c                                     |  47 ++
 net/tap.c                                     | 185 ++++++--
 qapi/migration.json                           |  13 +-
 qapi/net.json                                 |   6 +-
 tests/functional/qemu_test/decorators.py      |  16 +
 tests/functional/x86_64/meson.build           |   1 +
 tests/functional/x86_64/test_tap_migration.py | 401 ++++++++++++++++++
 13 files changed, 792 insertions(+), 46 deletions(-)
 create mode 100644 tests/functional/x86_64/test_tap_migration.py

-- 
2.52.0