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=gUwWuZfO; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by passt.top (Postfix) with ESMTPS id 1DF615A004E for ; Fri, 24 Jan 2025 19:40:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1737744024; 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=Yekn3kN8YydiDFdYGMMjaBAi8BheLjyyaZFjjU3F16E=; b=gUwWuZfO5SbCZ+10VI8sRdzK4zChqf/hyFRgQ7Kp2/2Z8t6gFkpI24n4+fX+VdRVqPXvYY lmeJ9Yi4GB0N7JCbKfOHW/O06+BxWlaKYrW4WGU4SqGGqbmgo7uepUbQE/yJrsXzZLJgVX DaZb6649V8Ri8JzHcE2BfZ6ralmSFlM= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-649-T3YPAS_NNp6-61-1qmkhBg-1; Fri, 24 Jan 2025 13:40:22 -0500 X-MC-Unique: T3YPAS_NNp6-61-1qmkhBg-1 X-Mimecast-MFC-AGG-ID: T3YPAS_NNp6-61-1qmkhBg Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-385ded5e92aso1041026f8f.3 for ; Fri, 24 Jan 2025 10:40:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737744020; x=1738348820; 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=Yekn3kN8YydiDFdYGMMjaBAi8BheLjyyaZFjjU3F16E=; b=Iq1pC51a3QRuYDjCZ1qZ9mpT37eu9yEo7AYEQWmN06Ij9CmVdQHncxidOEF0tcmgQb GOjcs6oJyg4HwzNCMQtH5uucPJ0SR0uTYJSMt0O0VR4TV70fdc5lk/L4OwNxMRuuU1wF 0UzIL9UeUW5Z/UP3L902g332kk3VrEc7trYZyAZzSgk3A4WUKtuxHs/WJtWH2GdnYKAI YwLzI70xk91cQAOF0q50rVgpdNM6MzCHOGN/mFsggUDJTrN5EcYL7p+0e0pOhbtokYyP DI4ohB5gkBIPh8yL0XgWrK8ObZRQfp65Jijc92v9LQKZr6R9D8OQ7k+OWsl+QkXJi3vK PbNw== X-Gm-Message-State: AOJu0Yy3l/+T8meS4CM9OX1gF8zEe7/6Wud7j14fPDbKtfv9kbJ8c23A CTGE2sTB+ss0Xnd0/p6sabRhNqwUQtH2jHcJ6VvmzTMCCMyvZxJGFAl4jDrr+paYrmriSnSVT/J cjSX+G495ULT1hnID/olGDce5hzX4mkbLK1mgiv6MbYLB3uaLMiiV6r1ry9UTdunInW89qKU5Sk gGIr3RT5nC7kr2h/c7yIJO7w9/wbV6dsRz X-Gm-Gg: ASbGncu0VqQFkzCiMfi/SM9gWP/4nfWXpmp6tsk4DHtROEHDsma4GPJP3fuJgXwO3of 6XzGL8LInTp6ISJhlmvctmR3ite34eAQjYXBTMd57UFcWn0dGmcdd0zhCUPFSj+8gbTvICgltHL pY9MFkX0qONNuqHQ0sXnma4SMXRzjqZBFimtjjS3V9us2D4wsWYV3fLakdfUNZWl3J/nC8HnVom fcUVWNn7MUhDiMdhaj1+bHqgTdL+bQHuzcf9oPrDkRVU9StKee4UzbfePrj7y1ZKlpfaZdq9Czt iTT/J4lXcYnuzj2aWIJ23Po= X-Received: by 2002:a05:6000:188c:b0:38b:ed6f:f012 with SMTP id ffacd0b85a97d-38bf566e472mr29531494f8f.9.1737744019868; Fri, 24 Jan 2025 10:40:19 -0800 (PST) X-Google-Smtp-Source: AGHT+IHv/HgdRdDbZEl8hgE1MZqKkqcIbYQhRazJ1Wjm5EpdeqlAziIkWdsKyUewwwmxxSbtmMmB2w== X-Received: by 2002:a05:6000:188c:b0:38b:ed6f:f012 with SMTP id ffacd0b85a97d-38bf566e472mr29531472f8f.9.1737744019450; Fri, 24 Jan 2025 10:40:19 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38c2a1bb0d4sm3516388f8f.69.2025.01.24.10.40.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jan 2025 10:40:18 -0800 (PST) Date: Fri, 24 Jan 2025 19:40:16 +0100 From: Stefano Brivio To: Laurent Vivier Subject: Re: [PATCH] vhost-user: Implement an empty VHOST_USER_SEND_RARP command Message-ID: <20250124194016.4c26375c@elisabeth> In-Reply-To: <5af65c6f-3bab-4852-84ac-ca8f23123b2e@redhat.com> References: <20250124142137.2296704-1-lvivier@redhat.com> <20250124171016.322d665b@elisabeth> <5af65c6f-3bab-4852-84ac-ca8f23123b2e@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: _VGnsjzZ5wgmiRje9DnBrQ2UwGEynTO-ubgIg9-_-jM_1737744021 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: GGP4UIU3TUFCFYUUD27FUSGGQMXOBZUG X-Message-ID-Hash: GGP4UIU3TUFCFYUUD27FUSGGQMXOBZUG 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, 24 Jan 2025 19:35:33 +0100 Laurent Vivier wrote: > On 24/01/2025 17:10, Stefano Brivio wrote: > > On Fri, 24 Jan 2025 15:21:37 +0100 > > Laurent Vivier wrote: > > > >> Passt cannot manage and doesn't need to manage the broadcast of a fake RARP, > >> but QEMU will report an error message if Passt doesn't implement it. > >> > >> Implement an empty SEND_RARP command to silence QEMU error message. > >> > >> Signed-off-by: Laurent Vivier > >> --- > >> vhost_user.c | 28 +++++++++++++++++++++++++++- > >> 1 file changed, 27 insertions(+), 1 deletion(-) > >> > >> diff --git a/vhost_user.c b/vhost_user.c > >> index f12dec5ddc58..e6633ae75ce8 100644 > >> --- a/vhost_user.c > >> +++ b/vhost_user.c > >> @@ -914,7 +914,8 @@ static bool vu_get_protocol_features_exec(struct vu_dev *vdev, > >> { > >> uint64_t features = 1ULL << VHOST_USER_PROTOCOL_F_REPLY_ACK | > >> 1ULL << VHOST_USER_PROTOCOL_F_LOG_SHMFD | > >> - 1ULL << VHOST_USER_PROTOCOL_F_DEVICE_STATE; > >> + 1ULL << VHOST_USER_PROTOCOL_F_DEVICE_STATE | > >> + 1ULL << VHOST_USER_PROTOCOL_F_RARP; > >> > >> (void)vdev; > >> vmsg_set_reply_u64(msg, features); > >> @@ -981,6 +982,30 @@ static bool vu_set_vring_enable_exec(struct vu_dev *vdev, > >> return false; > >> } > >> > >> +/** > >> + * vu_set_send_rarp_exec() - Broadcast a fake RARP to notify the migration > >> + * is terminated > > > > Fine, so we need to add this. > > > > But can we at least make it clear for our future benefit? That is, > > there's no such thing as "fake RARP". The only thing that's actually > > fake here is this callback. For others, see thread at: > > > > https://lore.kernel.org/qemu-devel/20250121100029.1106973-1-lvivier@redhat.com/ > > > > What about "Do nothing to silence QEMU bogus error message"? Claiming > > we are broadcasting a RARP message and not doing it is... confusing. > > I think it's interesting to have this comment as it comes from the vhost-user > specification as it describes the aim of the command, and we can add something like "but > as passt don't need to update any ARP table we do nothing only to silence QEMU bogus error > message". Eh, if we're already making it verbose, maybe we can go with something like: vhost-user specification says: "Broadcast ...", but passt ... > >> + * @vdev: vhost-user device > >> + * @vmsg: vhost-user message > >> + * > >> + * Return: False as no reply is requested > >> + */ > >> +static bool vu_send_rarp_exec(struct vu_dev *vdev, > >> + struct vhost_user_msg *msg) > >> +{ > >> + char macstr[ETH_ADDRSTRLEN]; > >> + > >> + (void)vdev; > >> + > >> + /* ignore the command */ > >> + > >> + debug("Ignore command VHOST_USER_SEND_RARP from %s", > > > > This is also a bit confusing, but I'm not sure I got it right. > > > > We don't actually get any message *from* the guest, correct? We get a > > message from QEMU telling us we should send a RARP broadcast *for* a > > given MAC address...? If I got it right, s/from/for/? > > Yes, you're right. > The purpose of this debug message was to identify for :) which interface QEMU wants this > broadcast. > > > > >> + eth_ntop((unsigned char *)&msg->payload.u64, macstr, > >> + sizeof(macstr))); > >> + > >> + return false; > >> +} > >> + > >> /** > >> * vu_set_migration_watch() - Add the migration file descriptor to epoll > >> * @vdev: vhost-user device > >> @@ -1177,6 +1202,7 @@ static bool (*vu_handle[VHOST_USER_MAX])(struct vu_dev *vdev, > >> [VHOST_USER_SET_VRING_CALL] = vu_set_vring_call_exec, > >> [VHOST_USER_SET_VRING_ERR] = vu_set_vring_err_exec, > >> [VHOST_USER_SET_VRING_ENABLE] = vu_set_vring_enable_exec, > >> + [VHOST_USER_SEND_RARP] = vu_send_rarp_exec, > >> [VHOST_USER_SET_DEVICE_STATE_FD] = vu_set_device_state_fd_exec, > >> [VHOST_USER_CHECK_DEVICE_STATE] = vu_check_device_state_exec, > >> }; -- Stefano