qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v5 2/5] migration: Set the migration tcp port


From: Juan Quintela
Subject: Re: [Qemu-devel] [PATCH v5 2/5] migration: Set the migration tcp port
Date: Wed, 31 Jan 2018 13:35:33 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Peter Xu <address@hidden> wrote:
> On Mon, Jan 29, 2018 at 01:17:51PM +0100, Juan Quintela wrote:
>> We can set the port parameter as zero.  This patch lets us know what
>> port the system was choosen for us.  Now we can migrate to this place.
>> 
>> Signed-off-by: Juan Quintela <address@hidden>
>> 
>> --
>> 
>> This was migrate_set_uri(), but as we only need the tcp_port, change
>> to that one.
>> ---
>>  migration/migration.c | 10 ++++++++++
>>  migration/migration.h |  2 ++
>>  migration/socket.c    | 35 ++++++++++++++++++++++++++++++-----
>>  3 files changed, 42 insertions(+), 5 deletions(-)
>> 
>> diff --git a/migration/migration.c b/migration/migration.c
>> index eb6958dcda..53818a87af 100644
>> --- a/migration/migration.c
>> +++ b/migration/migration.c
>> @@ -245,6 +245,16 @@ void migrate_send_rp_req_pages(MigrationIncomingState 
>> *mis, const char *rbname,
>>      }
>>  }
>>  
>> +void migrate_set_port(const uint16_t port, Error **errp)
>> +{
>> +    MigrateSetParameters p = {
>> +        .has_x_tcp_port = true,
>> +        .x_tcp_port = port,
>> +    };
>> +
>> +    qmp_migrate_set_parameters(&p, errp);
>
> If we are calling qmp_migrate_set_parameters() here, does it mean that
> user can also set this parameter via QMP?

Yeap.  We do that, or we invent yet another mechanism to update the
tcp_port parameter :-(

You can't have both.

if the user modifies it, it just shots itself it its feet, no?

>>                           "migration-socket-listener");
>>  
>>      if (qio_channel_socket_listen_sync(listen_ioc, saddr, errp) < 0) {
>>          object_unref(OBJECT(listen_ioc));
>> -        return;
>> +        return NULL;
>> +    }
>> +
>> +    address = qio_channel_socket_get_local_address(listen_ioc, errp);
>
> [1]
>
>> +    if (address < 0) {
>> +        object_unref(OBJECT(listen_ioc));
>> +        return NULL;
>>      }
>>  
>>      qio_channel_add_watch(QIO_CHANNEL(listen_ioc),
>
> [2]
>
>> @@ -178,14 +186,28 @@ static void 
>> socket_start_incoming_migration(SocketAddress *saddr,
>>                            socket_accept_incoming_migration,
>>                            listen_ioc,
>>                            (GDestroyNotify)object_unref);
>> +    return address;
>>  }
>>  
>>  void tcp_start_incoming_migration(const char *host_port, Error **errp)
>>  {
>>      Error *err = NULL;
>>      SocketAddress *saddr = tcp_build_address(host_port, &err);
>> +
>>      if (!err) {
>> -        socket_start_incoming_migration(saddr, &err);
>> +        SocketAddress *address = socket_start_incoming_migration(saddr, 
>> &err);
>> +
>> +        if (address) {
>> +            unsigned long long port;
>> +
>> +            if (parse_uint_full(address->u.inet.port, &port, 10) < 0) {
>> +                error_setg(errp, "error parsing port in '%s'",
>> +                           address->u.inet.port);
>> +            } else {
>> +                migrate_set_port(port, errp);
>> +            }
>
> If *errp is non-NULL when reach here (I don't know when this will
> happen, though), would there be a dangling incoming task in main
> thread (which was created during socket_start_incoming_migration at
> [2])?
>
> Not sure whether it can be fixed by moving the set port logic to [1]
> above.  Then the watch won't be created only if set port succeeded.

Ok, will take a look at reorganizing the code.

Thanks for the review.

Later, Juan.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]