From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=ZU+OrDr/; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id BB49F5A061C for ; Fri, 17 Jan 2025 13:44:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1737117892; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MVaxJSxmRbZzyWYXpeMEHbnrvHlbvQ/hAqbqTMINKEg=; b=ZU+OrDr/AfkxjSREqs6s/apS7X7YYDx4VXrrDkg6mCFhI1PvmmyO4/7HjdhuBOC2/JcHI6 cIOPoFMBJUGIsnWZh+SxJLX3CUjS0ukO2DnfH11WUtTv/sqKM8+9qgllbKfCEir7qZqrJa WlUH0M5Iu16PPYMLWqYypV8rHr5izbQ= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-172-E2ZVSYeVPyi-ZhN-0see_w-1; Fri, 17 Jan 2025 07:44:51 -0500 X-MC-Unique: E2ZVSYeVPyi-ZhN-0see_w-1 X-Mimecast-MFC-AGG-ID: E2ZVSYeVPyi-ZhN-0see_w Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-436225d4389so14306865e9.1 for ; Fri, 17 Jan 2025 04:44:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737117889; x=1737722689; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=MVaxJSxmRbZzyWYXpeMEHbnrvHlbvQ/hAqbqTMINKEg=; b=XVQQJAuM3k/sbN8zXaOgYvNFiHcD3+wE17EZ1lXLuqsVV33TbW6QiPqxcP8SrKt6zs FL7ulM1pbmPDbayx2XvLBewsAzlwsWsDwLF8Oe2XTciwxwxhFfTHaex8KKukz71W1Y7u E1eLmp/L3LmtjkAMJ7L77fqxYjQgIU2NasRIYkmau2ReuZNPloEyuxwEwHJHB+ZJnpB3 f0HTF7G3mnZNdnhalLzAfmD9OoaSNAIGpLLHMysnHF4j3tWrF4q3cPIUjJULSWXgOUWO 47Y6vqlrW8RLfIdgQnG0l3KNhTh7oGfiIeRDjqrxaxp3Qtb5+pticIaf8eUEbY391Lmz 31OA== X-Gm-Message-State: AOJu0YwPYNkWbezQGgYvRQMxqnUJYv7eUftAlBEDnIDgTP2fori7C9Sd klnUaBhjHXDT0exNWyqzvMHjKNioix5J4sgHhOWAAzUw0hiX+Erw20c+m1ltU8E7Ausk7Bzm3DQ Hy5B85qjkSppBaWNq46V620ApWpbI3wRIjx9vLKh6wE4ch5tQJp93zunHFSHWrNUAHwfV+h9fQd z/SrBPDdL3fPkD6L2yPrMitjMvSfUB5fWv X-Gm-Gg: ASbGncsf6HTHlm4ZMckPZknf447FiB3lO2XrYEEdVXyUsKIKVV6AbgWcJM9LgqJqhaR ZshdbwL9rXtYqCkcyYwyEasAOhuZcjV783JeSox3gOAilnsJhRVTDkx30SvVcif5uxaV+7yOnqs gxac8FzVTIyKH72dP2RrRGth0/TLEw2Sy3h8JgSTToSfCHohu6zMiXhIax7+psXPr0OJr/pUK1X R98qLfgwyXVknOJE7FZWJ/Ps2nP/HEQnaNLpwpvf2jFCXKj6OQlajNaecZw3ZmgvUw1DjB2cpPM 2oEimaZRqA== X-Received: by 2002:a05:6000:1fa5:b0:38a:88d0:1c9c with SMTP id ffacd0b85a97d-38bf5aeb3bfmr1908380f8f.17.1737117888651; Fri, 17 Jan 2025 04:44:48 -0800 (PST) X-Google-Smtp-Source: AGHT+IEsU5uIxbhkW2QcEBlqSZss/IxDS5Ba1IzRs1T5eTHRpa6dp64VWeXsCG058ek3sSJHqnxq3g== X-Received: by 2002:a05:6000:1fa5:b0:38a:88d0:1c9c with SMTP id ffacd0b85a97d-38bf5aeb3bfmr1908348f8f.17.1737117888039; Fri, 17 Jan 2025 04:44:48 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38bf327df12sm2454888f8f.92.2025.01.17.04.44.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jan 2025 04:44:47 -0800 (PST) Date: Fri, 17 Jan 2025 13:44:45 +0100 From: Stefano Brivio To: Laurent Vivier Subject: Re: [PATCH 0/9] vhost-user: Migration support Message-ID: <20250117134445.5b341bdd@elisabeth> In-Reply-To: <329e349d-f86c-479b-97ee-61397aa28c60@redhat.com> References: <20241219111400.2352110-1-lvivier@redhat.com> <329e349d-f86c-479b-97ee-61397aa28c60@redhat.com> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: qOnB05sgL2mSK14uSa5guUtMSYL8USUPMbL3Jc_DBlk_1737117890 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: FQ5XOYWYTEHFB2WOVVX3GTC5QFBP7SWQ X-Message-ID-Hash: FQ5XOYWYTEHFB2WOVVX3GTC5QFBP7SWQ X-MailFrom: sbrivio@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Fri, 17 Jan 2025 13:13:36 +0100 Laurent Vivier wrote: > On 19/12/2024 12:13, Laurent Vivier wrote: > > This series allows a QEMU guest to be migrated while it is connected > > to Passt using vhost-user interface. > > > > There are two parts: > > > > - first part enables the migration of QEMU without transferring the > > internal state of Passt. All connections are lost. > > > > This is done by implementing VHOST_USER_SET_LOG_FD and > > VHOST_USER_SET_LOG_BASE commands (and enabling > > VHOST_USER_PROTOCOL_F_LOG_SHMFD feature) > > > > "vhost-user: add VHOST_USER_SET_LOG_FD command" > > "vhost-user: add VHOST_USER_SET_LOG_BASE command" > > "vhost-user: Report to front-end we support VHOST_USER_PROTOCOL_F_LOG_SHMFD" > > > > - second part allows source Passt instance to send its internal > > state using QEMU migration channel to destination Passt instance. > > > > This is done implementing VHOST_USER_SET_DEVICE_STATE_FD and > > VHOST_USER_CHECK_DEVICE_STATE (and enabling > > VHOST_USER_PROTOCOL_F_DEVICE_STATE feature). > > > > "vhost-user: add VHOST_USER_CHECK_DEVICE_STATE command" > > "vhost-user: add VHOST_USER_SET_DEVICE_STATE_FD command" > > "vhost-user: Report to front-end we support VHOST_USER_PROTOCOL_F_DEVICE_STATE" > > > > For now, it only implements the function needed to transfer the > > state but no state is transferred. > > > > VHOST_USER_PROTOCOL_F_DEVICE_STATE is implemented in QEMU > > only for vhost-user-fs, to be able to use it with virtio-net > > I have proposed a patch upstream: > > > > https://patchew.org/QEMU/20241218143453.1573185-1-lvivier@redhat.com/ > > > > Laurent Vivier (9): > > virtio: Use const pointer for vu_dev > > vhost-user: update protocol features and commands list > > vhost-user: add VHOST_USER_SET_LOG_FD command > > vhost-user: Pass vu_dev to more virtio functions > > vhost-user: add VHOST_USER_SET_LOG_BASE command > > vhost-user: Report to front-end we support > > VHOST_USER_PROTOCOL_F_LOG_SHMFD > > vhost-user: add VHOST_USER_CHECK_DEVICE_STATE command > > vhost-user: add VHOST_USER_SET_DEVICE_STATE_FD command > > vhost-user: Report to front-end we support > > VHOST_USER_PROTOCOL_F_DEVICE_STATE > > > > epoll_type.h | 2 + > > passt.c | 4 + > > util.h | 3 + > > vhost_user.c | 251 ++++++++++++++++++++++++++++++++++++++++++++++++++- > > vhost_user.h | 50 +++++++++- > > virtio.c | 116 +++++++++++++++++++++--- > > virtio.h | 32 +++++-- > > vu_common.c | 59 +++++++++++- > > vu_common.h | 3 +- > > 9 files changed, 484 insertions(+), 36 deletions(-) > > > > Another point: > > vhost-user can ask backend (passt) to send a notification at the end of the migration on > the destination side to the network to update the network topology. Do we need this? > > This is VHOST_USER_SEND_RARP: > "Ask vhost user back-end to broadcast a fake RARP to notify the migration is terminated > for guest that does not support GUEST_ANNOUNCE. > > Only legal if feature bit VHOST_USER_F_PROTOCOL_FEATURES is present in > VHOST_USER_GET_FEATURES and protocol feature bit VHOST_USER_PROTOCOL_F_RARP is present in > VHOST_USER_GET_PROTOCOL_FEATURES. The first 6 bytes of the payload contain the mac address > of the guest to allow the vhost user back-end to construct and broadcast the fake RARP." This isn't really clear :( ...what does "fake RARP" even mean? RARP is a protocol, and an obsolete one, despite: https://en.wikipedia.org/wiki/Reverse_Address_Resolution_Protocol#Modern_Day_Uses Anyway, it comes from 3e866365e1eb ("vhost user: add rarp sending after live migration for legacy guest"). I have no idea what "legacy" means here, but I'm under the impression that somebody just needed a way to notify the guest of the finished migration (nothing related to networking) and, correct me if I'm wrong, the French word for "fake" is rather similar to the one for "dummy". So my understanding of it is that they would just send a dummy packet, and a RARP broadcast would be a good candidate because it's otherwise unused, but wouldn't raise any firewall alert. Or maybe "legacy" has something to do with VMware vSphere, and there was some guest previously running on VMware vSphere that needs a RARP packet to "proceed" with something after the migration. If that's the case, and if there's still something like that around, I guess that ideally we want it for compatibility, but it's *very* unlikely to ever bite us. So all in all I would say that if the implementation is very small and unproblematic we can hack up something in arp.c to build a RARP packet (example here: https://wiki.wireshark.org/RARP but that's a request, not a broadcast). Otherwise I wouldn't really care until somebody asks. -- Stefano