Re: [PATCH v6 16/19] qapi: add interface for backend-transfer virtio-net/tap migration

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Oct 06, 2025 at 04:38:32PM +0200, Markus Armbruster wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > On Mon, Oct 06, 2025 at 03:23:06PM +0200, 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>
> >> > ---
> >> >  include/qapi/util.h | 17 ++++++++++++++++
> >> >  migration/options.c | 32 ++++++++++++++++++++++++++++++
> >> >  migration/options.h |  2 ++
> >> >  qapi/migration.json | 47 ++++++++++++++++++++++++++++++++++++---------
> >> >  4 files changed, 89 insertions(+), 9 deletions(-)
> >> >
> >> > diff --git a/include/qapi/util.h b/include/qapi/util.h
> >> > index 29bc4eb865..b953402416 100644
> >> > --- a/include/qapi/util.h
> >> > +++ b/include/qapi/util.h
> >> > @@ -69,4 +69,21 @@ int parse_qapi_name(const char *name, bool complete);
> >> >          _len;                                                       \
> >> >      })
> >> >  
> >> > +/*
> >> > + * For any GenericList @list, return true if it contains specified
> >> > + * element.
> >> > + */
> >> > +#define QAPI_LIST_CONTAINS(list, el)                                \
> >> > +    ({                                                              \
> >> > +        bool _found = false;                                        \
> >> > +        typeof_strip_qual(list) _tail;                              \
> >> > +        for (_tail = list; _tail != NULL; _tail = _tail->next) {    \
> >> > +            if (_tail->value == el) {                               \
> >> > +                _found = true;                                      \
> >> > +                break;                                              \
> >> > +            }                                                       \
> >> > +        }                                                           \
> >> > +        _found;                                                     \
> >> > +    })
> >> > +
> >> 
> >> Not a fan of lengthy macros.
> >> 
> >> There's a single use below: migrate_virtio_net_tap().  I can't see
> >> potential uses for such a search in existing code.
> >
> > However, QAPI_LIST_FOR_EACH can potentially be used to implement
> > QAPI_LIST_LENGTH.
> >
> > #define QAPI_LIST_FOR_EACH(list, tail)                    \
> >         for (tail = list; tail != NULL; tail = tail->next)
> >
> > and
> >
> > #define QAPI_LIST_LENGTH(list)                                      \
> >     ({                                                              \
> >         size_t _len = 0;                                            \
> >         typeof_strip_qual(list) _tail;                              \
> >         QAPI_LIST_FOR_EACH(list, tail) {                            \
> >             _len++;                                                 \
> >         }                                                           \
> >         _len;                                                       \
> >     })
> 
> Yes, but would QAPI_LIST_FOR_EACH be better than the straightfoward &
> simple for-loop?
> 
> [...]

Well I don't really remember off hand how QAPI lists work so for me I'd
have to otherwise go read the code to check this is the right way to
walk this list.

Which reminds me, why are these custom like this and not just QLIST?


-- 
MST