From: Markus Armbruster <armbru@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
Cc: mst@redhat.com, qemu-devel@nongnu.org, philmd@linaro.org,
thuth@redhat.com, eblake@redhat.com, michael.roth@amd.com,
farosas@suse.de, peterx@redhat.com, berrange@redhat.com,
jasowang@redhat.com, steven.sistare@oracle.com,
leiyang@redhat.com, davydov-max@yandex-team.ru,
yc-core@yandex-team.ru
Subject: Re: [PATCH v6 16/19] qapi: add interface for backend-transfer virtio-net/tap migration
Date: Tue, 07 Oct 2025 13:42:21 +0200 [thread overview]
Message-ID: <87jz17q6oy.fsf@pond.sub.org> (raw)
In-Reply-To: <cea1ebb9-2a14-486b-a016-2378c4b4ffa4@yandex-team.ru> (Vladimir Sementsov-Ogievskiy's message of "Tue, 7 Oct 2025 11:57:41 +0300")
Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> writes:
> On 06.10.25 16:23, Markus Armbruster wrote:
>> Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru> writes:
>>
>>> To migrate virtio-net TAP device backend (including open fds) locally,
>>> user should simply set migration parameter
>>>
>>> backend-transfer = ["virtio-net-tap"]
>>>
>>> Why not simple boolean? To simplify migration to further versions,
>>> when more devices will support backend-transfer migration.
>>>
>>> Alternatively, we may add per-device option to disable backend-transfer
>>> migration, but still:
>>>
>>> 1. It's more comfortable to set same capabilities/parameters on both
>>> source and target QEMU, than care about each device.
>>>
>>> 2. To not break the design, that machine-type + device options +
>>> migration capabilities and parameters are fully define the resulting
>>> migration stream. We'll break this if add in future more
>>> backend-transfer support in devices under same backend-transfer=true
>>> parameter.
>>>
>>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
[...]
>>> diff --git a/migration/options.h b/migration/options.h
>>> index 82d839709e..55c0345433 100644
>>> --- a/migration/options.h
>>> +++ b/migration/options.h
>>> @@ -87,6 +87,8 @@ const char *migrate_tls_hostname(void);
>>> uint64_t migrate_xbzrle_cache_size(void);
>>> ZeroPageDetection migrate_zero_page_detection(void);
>>>
>>> +bool migrate_virtio_net_tap(void);
>>> +
>>> /* parameters helpers */
>>>
>>> bool migrate_params_check(MigrationParameters *params, Error **errp);
>>> diff --git a/qapi/migration.json b/qapi/migration.json
>>> index 2387c21e9c..e39785dc07 100644
>>> --- a/qapi/migration.json
>>> +++ b/qapi/migration.json
>>> @@ -747,6 +747,18 @@
>>> '*transform': 'BitmapMigrationBitmapAliasTransform'
>>> } }
>>>
>>> +##
>>> +# @BackendTransfer:
>>> +#
>>> +# @virtio-net-tap: Enable backend-transfer migration for virtio-net/tap. When
>>> +# enabled, TAP fds and all related state is passed to target QEMU through
>>> +# migration channel (which should be unix socket).
>>
>> Suggest "are passed to the destination in the migration channel" and
>> "should be a UNIX domain socket".
>>
>> docs/devel/qapi-code-gen.rst:
>>
>> For legibility, wrap text paragraphs so every line is at most 70
>> characters long.
>>
>> Separate sentences with two spaces.
>
> Ok. We do lack this check in checkpatch
Would be nice, yes.
>>> +#
>>> +# Since: 10.2
>>> +##
>>> +{ 'enum': 'BackendTransfer',
>>> + 'data': [ 'virtio-net-tap' ] }
>>> +
>>> ##
>>> # @BitmapMigrationNodeAlias:
>>> #
>>> @@ -924,10 +936,14 @@
>>> # only has effect if the @mapped-ram capability is enabled.
>>> # (Since 9.1)
>>> #
>>> +# @backend-transfer: List of targets to enable backend-transfer
>>> +# migration for. This requires migration channel to be a unix
>>> +# socket (to pass fds through). (Since 10.2)
>>
>> Elsewhere, we describe the same restriction like this:
>>
>> This CPR channel must support
>> # file descriptor transfer with SCM_RIGHTS, i.e. it must be a
>> # UNIX domain socket.
>>
>
> Thanks, I'll copy this phrasing to be consistent.
>
>>> +#
>>> # Features:
>>> #
>>> -# @unstable: Members @x-checkpoint-delay and
>>> -# @x-vcpu-dirty-limit-period are experimental.
>>> +# @unstable: Members @x-checkpoint-delay,
>>> +# @x-vcpu-dirty-limit-period and @backend-transfer are experimental.
>>
>> List members in alphabetical order, please.
>>
>>> #
>>> # Since: 2.4
>>> ##
>>> @@ -950,7 +966,8 @@
>>> 'vcpu-dirty-limit',
>>> 'mode',
>>> 'zero-page-detection',
>>> - 'direct-io'] }
>>> + 'direct-io',
>>> + 'backend-transfer' ] }
>>
>> Forgot feature 'unstable'?
>
> Opps. Interesting, how it compiles? Usually, inconsistencies between
> QAPI comments and definitions are hardly checked.
You found a gap in the checking.
[...]
next prev parent reply other threads:[~2025-10-07 11:43 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-23 10:00 [PATCH v6 00/19] virtio-net: live-TAP local migration Vladimir Sementsov-Ogievskiy
2025-09-23 10:00 ` [PATCH v6 01/19] net/tap: net_init_tap_one(): drop extra error propagation Vladimir Sementsov-Ogievskiy
2025-09-23 10:00 ` [PATCH v6 02/19] net/tap: net_init_tap_one(): move parameter checking earlier Vladimir Sementsov-Ogievskiy
2025-09-23 10:00 ` [PATCH v6 03/19] net/tap: rework net_tap_init() Vladimir Sementsov-Ogievskiy
2025-09-23 10:00 ` [PATCH v6 04/19] net/tap: pass NULL to net_init_tap_one() in cases when scripts are NULL Vladimir Sementsov-Ogievskiy
2025-09-23 10:00 ` [PATCH v6 05/19] net/tap: rework scripts handling Vladimir Sementsov-Ogievskiy
2025-09-23 10:39 ` Vladimir Sementsov-Ogievskiy
2025-09-23 10:00 ` [PATCH v6 06/19] net/tap: setup exit notifier only when needed Vladimir Sementsov-Ogievskiy
2025-09-23 10:00 ` [PATCH v6 07/19] net/tap: split net_tap_fd_init() Vladimir Sementsov-Ogievskiy
2025-09-23 10:00 ` [PATCH v6 08/19] net/tap: tap_set_sndbuf(): add return value Vladimir Sementsov-Ogievskiy
2025-09-23 10:01 ` [PATCH v6 09/19] net/tap: rework tap_set_sndbuf() Vladimir Sementsov-Ogievskiy
2025-09-23 10:01 ` [PATCH v6 10/19] net/tap: rework sndbuf handling Vladimir Sementsov-Ogievskiy
2025-09-23 10:01 ` [PATCH v6 11/19] net/tap: introduce net_tap_setup() Vladimir Sementsov-Ogievskiy
2025-09-23 10:01 ` [PATCH v6 12/19] net/tap: move vhost fd initialization to net_tap_new() Vladimir Sementsov-Ogievskiy
2025-09-23 10:01 ` [PATCH v6 13/19] net/tap: finalize net_tap_set_fd() logic Vladimir Sementsov-Ogievskiy
2025-09-23 10:01 ` [PATCH v6 14/19] migration: add MIG_EVENT_PRE_INCOMING Vladimir Sementsov-Ogievskiy
2025-09-30 19:25 ` Peter Xu
2025-09-23 10:01 ` [PATCH v6 15/19] net/tap: postpone tap setup to pre-incoming Vladimir Sementsov-Ogievskiy
2025-09-23 10:01 ` [PATCH v6 16/19] qapi: add interface for backend-transfer virtio-net/tap migration Vladimir Sementsov-Ogievskiy
2025-10-06 13:23 ` Markus Armbruster
2025-10-06 13:33 ` Michael S. Tsirkin
2025-10-06 14:38 ` Markus Armbruster
2025-10-06 14:55 ` Michael S. Tsirkin
2025-10-06 17:06 ` Markus Armbruster
2025-10-07 8:57 ` Vladimir Sementsov-Ogievskiy
2025-10-07 11:42 ` Markus Armbruster [this message]
2025-09-23 10:01 ` [PATCH v6 17/19] virtio-net: support backend-transfer migration for virtio-net/tap Vladimir Sementsov-Ogievskiy
2025-09-23 10:01 ` [PATCH v6 18/19] tests/functional: add skipWithoutSudo() decorator Vladimir Sementsov-Ogievskiy
2025-09-23 10:01 ` [PATCH v6 19/19] tests/functional: add test_x86_64_tap_migration Vladimir Sementsov-Ogievskiy
2025-09-24 8:02 ` [PATCH v6 00/19] virtio-net: live-TAP local migration Lei Yang
2025-10-01 16:33 ` Maksim Davydov
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=87jz17q6oy.fsf@pond.sub.org \
--to=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=davydov-max@yandex-team.ru \
--cc=eblake@redhat.com \
--cc=farosas@suse.de \
--cc=jasowang@redhat.com \
--cc=leiyang@redhat.com \
--cc=michael.roth@amd.com \
--cc=mst@redhat.com \
--cc=peterx@redhat.com \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=steven.sistare@oracle.com \
--cc=thuth@redhat.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 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).