All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Steve Sistare <steven.sistare@oracle.com>
Cc: qemu-devel@nongnu.org,  Peter Xu <peterx@redhat.com>,
	 Fabiano Rosas <farosas@suse.de>,
	 David Hildenbrand <david@redhat.com>,
	 Marcel Apfelbaum <marcel.apfelbaum@gmail.com>,
	 Eduardo Habkost <eduardo@habkost.net>,
	 Philippe Mathieu-Daude <philmd@linaro.org>,
	 Paolo Bonzini <pbonzini@redhat.com>,
	 "Daniel P. Berrange" <berrange@redhat.com>
Subject: Re: [PATCH V4 09/19] migration: incoming channel
Date: Thu, 05 Dec 2024 16:23:53 +0100	[thread overview]
Message-ID: <87ser2cfw6.fsf@pond.sub.org> (raw)
In-Reply-To: <1733145611-62315-10-git-send-email-steven.sistare@oracle.com> (Steve Sistare's message of "Mon, 2 Dec 2024 05:20:01 -0800")

Steve Sistare <steven.sistare@oracle.com> writes:

> Extend the -incoming option to allow an @MigrationChannel to be specified.
> This allows channels other than 'main' to be described on the command
> line, which will be needed for CPR.
>
> Signed-off-by: Steve Sistare <steven.sistare@oracle.com>

[...]

> diff --git a/qemu-options.hx b/qemu-options.hx
> index 02b9118..fab50ce 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -4937,10 +4937,17 @@ DEF("incoming", HAS_ARG, QEMU_OPTION_incoming, \
>      "-incoming exec:cmdline\n" \
>      "                accept incoming migration on given file descriptor\n" \
>      "                or from given external command\n" \
> +    "-incoming @MigrationChannel\n" \
> +    "                accept incoming migration on the channel\n" \
>      "-incoming defer\n" \
>      "                wait for the URI to be specified via migrate_incoming\n",
>      QEMU_ARCH_ALL)
>  SRST
> +The -incoming option specifies the migration channel for an incoming
> +migration.  It may be used multiple times to specify multiple
> +migration channel types.

Really?  If I understand the code below correctly, the last -incoming
wins, and any previous ones are silently ignored.

>                            The channel type is specified in @MigrationChannel,
> +and is 'main' for all other forms of -incoming.
> +
>  ``-incoming tcp:[host]:port[,to=maxport][,ipv4=on|off][,ipv6=on|off]``
>    \ 
>  ``-incoming rdma:host:port[,ipv4=on|off][,ipv6=on|off]``
> @@ -4960,6 +4967,16 @@ SRST
>      Accept incoming migration as an output from specified external
>      command.
>  
> +``-incoming @MigrationChannel``
> +    Accept incoming migration on the channel.  See the QAPI documentation
> +    for the syntax of the @MigrationChannel data element.  For example:
> +    ::

I get what you're trying to express, but there's no precedence for
referring to QAPI types like @TypeName in option documentation.  But
let's ignore this until after we nailed down the actual interface, on
which I have questions below.

> +
> +        -incoming '{"channel-type": "main",
> +                    "addr": { "transport": "socket",
> +                              "type": "unix",
> +                              "path": "my.sock" }}'
> +
>  ``-incoming defer``
>      Wait for the URI to be specified via migrate\_incoming. The monitor
>      can be used to change settings (such as migration parameters) prior
> diff --git a/system/vl.c b/system/vl.c
> index 4151a79..2c24c60 100644
> --- a/system/vl.c
> +++ b/system/vl.c
> @@ -123,6 +123,7 @@
>  #include "qapi/qapi-visit-block-core.h"
>  #include "qapi/qapi-visit-compat.h"
>  #include "qapi/qapi-visit-machine.h"
> +#include "qapi/qapi-visit-migration.h"
>  #include "qapi/qapi-visit-ui.h"
>  #include "qapi/qapi-commands-block-core.h"
>  #include "qapi/qapi-commands-migration.h"
> @@ -159,6 +160,7 @@ typedef struct DeviceOption {
>  static const char *cpu_option;
>  static const char *mem_path;
>  static const char *incoming;
> +static MigrationChannelList *incoming_channels;
>  static const char *loadvm;
>  static const char *accelerators;
>  static bool have_custom_ram_size;
> @@ -1821,6 +1823,35 @@ static void object_option_add_visitor(Visitor *v)
>      QTAILQ_INSERT_TAIL(&object_opts, opt, next);
>  }
>  
> +static void incoming_option_parse(const char *str)
> +{
> +    MigrationChannel *channel;
> +
> +    if (str[0] == '{') {
> +        QObject *obj = qobject_from_json(str, &error_fatal);
> +        Visitor *v = qobject_input_visitor_new(obj);
> +
> +        qobject_unref(obj);
> +        visit_type_MigrationChannel(v, "channel", &channel, &error_fatal);
> +        visit_free(v);
> +    } else if (!strcmp(str, "defer")) {
> +        channel = NULL;
> +    } else {
> +        migrate_uri_parse(str, &channel, &error_fatal);
> +    }
> +
> +    /* New incoming spec replaces the previous */
> +
> +    if (incoming_channels) {
> +        qapi_free_MigrationChannelList(incoming_channels);
> +    }
> +    if (channel) {
> +        incoming_channels = g_new0(MigrationChannelList, 1);
> +        incoming_channels->value = channel;
> +    }
> +    incoming = str;
> +}

@incoming is set to @optarg.

@incoming_channels is set to a MigrationChannelList of exactly one
element, parsed from @incoming.  Except when @incoming is "defer", then
@incoming_channels is set to null.

@incoming is only ever used as a flag.  Turn it into a bool?

Oh, wait...  see my comment on the next hunk.

Option -incoming resembles QMP command migrate-incoming.  Differences:

* migrate-incoming keeps legacy URI and modern argument separate: there
  are two named arguments, and exactly one of them must be passed.
  -incoming overloads them: if @optarg starts with '{', it's modern,
  else legacy URI.

  Because of that, -incoming *only* supports JSON syntax for modern, not
  dotted keys.  Other JSON-capable arguments support both.

  How can a management application detect that -incoming supports
  modern?

  Sure overloading -incoming this way is a good idea?

* migrate-incoming takes a list of channels, currently restricted to a
  single channel.  -incoming takes a channel.  If we lift the
  restriction, -incoming syntax will become even messier: we'll have to
  additionally overload list of channel.

  Should -incoming take a list from the start, like migrate-incoming
  does?

> +
>  static void object_option_parse(const char *str)
>  {
>      QemuOpts *opts;
> @@ -2730,7 +2761,7 @@ void qmp_x_exit_preconfig(Error **errp)
>      if (incoming) {
>          Error *local_err = NULL;
>          if (strcmp(incoming, "defer") != 0) {
> -            qmp_migrate_incoming(incoming, false, NULL, true, true,
> +            qmp_migrate_incoming(NULL, true, incoming_channels, true, true,
>                                   &local_err);

You move the parsing of legacy URI from within qmp_migrate_incoming()
into incoming_option_parse().

The alternative is not to parse it in incoming_option_parse(), but pass
it to qmp_migrate_incoming() like this:

               qmp_migrate_incoming(incoming, !incoming, incoming_channels,
                                    true, true, &local_err);

>              if (local_err) {
>                  error_reportf_err(local_err, "-incoming %s: ", incoming);
> @@ -3477,7 +3508,7 @@ void qemu_init(int argc, char **argv)
>                  if (!incoming) {
>                      runstate_set(RUN_STATE_INMIGRATE);
>                  }
> -                incoming = optarg;
> +                incoming_option_parse(optarg);
>                  break;
>              case QEMU_OPTION_only_migratable:
>                  only_migratable = 1;



  reply	other threads:[~2024-12-05 15:24 UTC|newest]

Thread overview: 78+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-02 13:19 [PATCH V4 00/19] Live update: cpr-transfer Steve Sistare
2024-12-02 13:19 ` [PATCH V4 01/19] backends/hostmem-shm: factor out allocation of "anonymous shared memory with an fd" Steve Sistare
2024-12-09 17:36   ` Peter Xu
2024-12-12 20:37     ` Steven Sistare
2024-12-02 13:19 ` [PATCH V4 02/19] physmem: fd-based shared memory Steve Sistare
2024-12-09 19:42   ` Peter Xu
2024-12-12 20:38     ` Steven Sistare
2024-12-12 21:22       ` Peter Xu
2024-12-13 16:41         ` Steven Sistare
2024-12-13 17:05           ` Steven Sistare
2024-12-16 18:19           ` Peter Xu
2024-12-17 21:54             ` Steven Sistare
2024-12-17 22:46               ` Peter Xu
2024-12-18 16:34                 ` Steven Sistare
2024-12-02 13:19 ` [PATCH V4 03/19] memory: add RAM_PRIVATE Steve Sistare
2024-12-09 19:45   ` Peter Xu
2024-12-02 13:19 ` [PATCH V4 04/19] machine: aux-ram-share option Steve Sistare
2024-12-05  8:25   ` Markus Armbruster
2024-12-05 14:24     ` Steven Sistare
2024-12-05 12:08   ` Markus Armbruster
2024-12-05 12:19     ` Markus Armbruster
2024-12-05 14:24       ` Steven Sistare
2024-12-09 19:54   ` Peter Xu
2024-12-12 20:38     ` Steven Sistare
2024-12-12 21:22       ` Peter Xu
2024-12-02 13:19 ` [PATCH V4 05/19] migration: cpr-state Steve Sistare
2024-12-02 13:19 ` [PATCH V4 06/19] physmem: preserve ram blocks for cpr Steve Sistare
2024-12-09 20:07   ` Peter Xu
2024-12-12 20:38     ` Steven Sistare
2024-12-12 22:48       ` Peter Xu
2024-12-13 15:21         ` Peter Xu
2024-12-13 15:30           ` Steven Sistare
2024-12-18 16:34             ` Steven Sistare
2024-12-18 17:00               ` Peter Xu
2024-12-18 20:22                 ` Steven Sistare
2024-12-18 20:33                   ` Peter Xu
2024-12-02 13:19 ` [PATCH V4 07/19] hostmem-memfd: preserve " Steve Sistare
2024-12-18 19:53   ` Steven Sistare
2024-12-18 20:23     ` Peter Xu
2024-12-02 13:20 ` [PATCH V4 08/19] hostmem-shm: " Steve Sistare
2024-12-12 17:38   ` Peter Xu
2024-12-02 13:20 ` [PATCH V4 09/19] migration: incoming channel Steve Sistare
2024-12-05 15:23   ` Markus Armbruster [this message]
2024-12-05 20:45     ` Steven Sistare
2024-12-09 12:12       ` Markus Armbruster
2024-12-09 16:36         ` Peter Xu
2024-12-11  9:18         ` Markus Armbruster
2024-12-11 18:58         ` Steven Sistare
2024-12-10 12:46     ` Markus Armbruster
2024-12-02 13:20 ` [PATCH V4 10/19] migration: cpr channel Steve Sistare
2024-12-05 15:37   ` Markus Armbruster
2024-12-05 20:46     ` Steven Sistare
2024-12-06  9:31       ` Markus Armbruster
2024-12-18 19:53         ` Steven Sistare
2024-12-18 20:27           ` Peter Xu
2024-12-18 20:31             ` Steven Sistare
2024-12-02 13:20 ` [PATCH V4 11/19] migration: SCM_RIGHTS for QEMUFile Steve Sistare
2024-12-02 13:20 ` [PATCH V4 12/19] migration: VMSTATE_FD Steve Sistare
2024-12-02 13:20 ` [PATCH V4 13/19] migration: cpr-transfer save and load Steve Sistare
2024-12-02 13:20 ` [PATCH V4 14/19] migration: cpr-transfer mode Steve Sistare
2024-12-04 16:10   ` Steven Sistare
2024-12-10 12:26   ` Markus Armbruster
2024-12-11 22:05     ` Steven Sistare
2024-12-02 13:20 ` [PATCH V4 15/19] tests/migration-test: memory_backend Steve Sistare
2024-12-02 13:20 ` [PATCH V4 16/19] tests/qtest: defer connection Steve Sistare
2024-12-18 21:02   ` Steven Sistare
2024-12-19 15:46   ` Peter Xu
2024-12-19 22:33     ` Steven Sistare
2024-12-02 13:20 ` [PATCH V4 17/19] tests/migration-test: " Steve Sistare
2024-12-02 13:20 ` [PATCH V4 18/19] migration-test: cpr-transfer Steve Sistare
2024-12-18 21:03   ` Steven Sistare
2024-12-19 16:56   ` Peter Xu
2024-12-19 22:34     ` Steven Sistare
2024-12-20 15:41       ` Peter Xu
2024-12-02 13:20 ` [PATCH V4 19/19] migration: cpr-transfer documentation Steve Sistare
2024-12-18 21:03   ` Steven Sistare
2024-12-19 17:02   ` Peter Xu
2024-12-19 22:35     ` Steven Sistare

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=87ser2cfw6.fsf@pond.sub.org \
    --to=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=david@redhat.com \
    --cc=eduardo@habkost.net \
    --cc=farosas@suse.de \
    --cc=marcel.apfelbaum@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=peterx@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=steven.sistare@oracle.com \
    /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.