qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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.

[...]



  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).