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=NxJDT98L; 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 149965A0271 for ; Fri, 24 Jan 2025 17:41:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1737736901; 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=hithnmpm4FwbCDlGW+AA4kErujiTE41cuWNORMQ7tZk=; b=NxJDT98LaL2HjeUPrb+cX0w3nLHlZ3BYUr8/FY65KzDwjM63KejaEMndcpRdhTR+kM8bto Z2cF2eVcYP72g8bVWFCYmdtfiTgThBQHpcTkuLzBccdBptiaYtcPgltBehOTpPWimY8WY3 It82j0bJfYyq5Wp7OCeEGXA8LFnTDhc= Received: from mail-ej1-f72.google.com (mail-ej1-f72.google.com [209.85.218.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-600-41EBOWB-PNuKdpfxpiQ-Dg-1; Fri, 24 Jan 2025 11:41:40 -0500 X-MC-Unique: 41EBOWB-PNuKdpfxpiQ-Dg-1 X-Mimecast-MFC-AGG-ID: 41EBOWB-PNuKdpfxpiQ-Dg Received: by mail-ej1-f72.google.com with SMTP id a640c23a62f3a-ab45150a216so319764566b.0 for ; Fri, 24 Jan 2025 08:41:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737736899; x=1738341699; 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=hithnmpm4FwbCDlGW+AA4kErujiTE41cuWNORMQ7tZk=; b=jDzR0ZWpCW1/XispP7ZeOakFafKKzBFe6K1bPLJ3XaT/XbVutIDRBwV6Flmy/Z+Pxn 0qCJMdjG6c6x7H21/dhMveC3QpTSI3OCxDNOucHhHHWB1gOv2EuTf79zB4ZvzHRamWPD PHSSQIAx2twpaKyuO56cnlHAWELT/KL7Zva26NIZXZn8ceTIZwAtnZh3k8Eo42lMSWRO irlbyTL/ZKe/kU7CKoJq5HvSZb2nftrbhEC3esJ+S6hZyGg6nbQObrtPVoqNxvXYfuLd xo74rNl6ug85qc7Q1WFCKLcpk1WI8F6mDXxZtSLT5Xnlt56MJWZyHr7MDVvTQtdtnkLH SSuQ== X-Gm-Message-State: AOJu0Yybu59UEjW6RPAUIE12J8FPwZFIcNd0tUscre36LG76AIwgeEgx tTmk+9ggCufpP7Ulv9R3c/yVzZrV/sGw0JZObQ/tQPW5+b24nPD8p+ZeCSGUUFzWaiHdPq+aBsA 0BmRl4fPoRBf2q4zhkhJAE47mifp4NC9trUtqAb+xZiMYQHRwYK1mE+LeCIM9yM7T2kxuQ54Wie /UKEPuWb75JMH0Pl3RBjosESMISf223Bg5 X-Gm-Gg: ASbGncsncTFzDF406fq/LlkHaBJp5f14vFNV5CQLmrPybw2tQBkrvvRYaIYbe8H7iy7 1J7tagWhrozPrrinAMYN/aOZPztFJTGsNpgzM14sihfTtlDlu0hHokySNoi11Ce6dK+SpGM+gi+ 6qcoWPqM3fPaO8TUEtKPsAHXKzNQEECLbm0e24xauYPrLvYIkFFEdgWGxYleJGtTKE73Pww7pQi O6HfEmd9zwCuxFAabfQRv5mQy9bDnpZNxfotXh4C+9pM6ME49MIHF/cyMFx4WDvHBF914Nh1nIr Ey7FNA== X-Received: by 2002:a05:600c:510c:b0:434:a1e7:27b0 with SMTP id 5b1f17b1804b1-438913ccd4amr358931815e9.11.1737735018886; Fri, 24 Jan 2025 08:10:18 -0800 (PST) X-Google-Smtp-Source: AGHT+IGCbrhYidG1GbaRX0881oSLWgsP7hrxwNd41FkqpNHN+FhF2CWY0hYDcM7ix0WMMi0zJKKHsw== X-Received: by 2002:a05:600c:510c:b0:434:a1e7:27b0 with SMTP id 5b1f17b1804b1-438913ccd4amr358931275e9.11.1737735018391; Fri, 24 Jan 2025 08:10:18 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [2a10:fc81:a806:d6a9::1]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38c2a18931esm3151278f8f.60.2025.01.24.08.10.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jan 2025 08:10:17 -0800 (PST) Date: Fri, 24 Jan 2025 17:10:16 +0100 From: Stefano Brivio To: Laurent Vivier Subject: Re: [PATCH] vhost-user: Implement an empty VHOST_USER_SEND_RARP command Message-ID: <20250124171016.322d665b@elisabeth> In-Reply-To: <20250124142137.2296704-1-lvivier@redhat.com> References: <20250124142137.2296704-1-lvivier@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: gYW2JQmsQW_y4QlLwmOYgxPiYfou4PHEIqK738M-er8_1737736899 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: N2GVN3KNIOJAVKC2RHTYAIBRVB3UJTHL X-Message-ID-Hash: N2GVN3KNIOJAVKC2RHTYAIBRVB3UJTHL 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 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. > + * @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/? > + 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