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=DdwsC4is; 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 84B975A004E for ; Fri, 24 Jan 2025 19:35:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1737743737; 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:autocrypt:autocrypt; bh=2MseZE5b49qU5BBUU2uZALzMfFh1N1aOcx1qQbWMS9k=; b=DdwsC4isyNwjIfAW/WP3OcpEa/5y16upiluerVchSMzHVVWzt1Ad902aTqeiRO9hrdSOHZ 42HUoDTeV7TQtRSsmMfAwxXLwVosHxj+VFQHz+/3ClP1hqyCesmmi3+1wmz5NA8dVKrcfT 1N+Rv7oNgaMUdca+LIj+wDWFCU5TqG8= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-394-EuJXsNIoPhqpruTFNzBqeQ-1; Fri, 24 Jan 2025 13:35:36 -0500 X-MC-Unique: EuJXsNIoPhqpruTFNzBqeQ-1 X-Mimecast-MFC-AGG-ID: EuJXsNIoPhqpruTFNzBqeQ Received: by mail-qv1-f69.google.com with SMTP id 6a1803df08f44-6d899291908so59950006d6.0 for ; Fri, 24 Jan 2025 10:35:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737743735; x=1738348535; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=2MseZE5b49qU5BBUU2uZALzMfFh1N1aOcx1qQbWMS9k=; b=IRSBx9+q3emDhm0AR31he6ELgJ2O4nqYGKpLGPmNmOD8E8tjdc+kXFF97mEJPMaZpe Qh7AjyDpoPIjklb7NpLlJ5KhAAHQo4PR6dl4dkm3JqON02lYfX882CftmloInVsp81x7 YSdBoiNa9r4n1eUhloMG78z3OUAYDDauqXYzBrlvxedQQagOdz4vRbnUNcM649D5BZmW nHEcfrfXsl7LehpkPDGMhyeOyczQCfy62nJ0qAsE1YmUC9eU7lyf8yCM5kmkI91q6oTc Qxg5WHWuY2PfvUjzEieZ2IJPFBfrR3p1/iuevtTzV2hHE5ZlvG5KeTix2FCV56CJ9cYa tUvg== X-Gm-Message-State: AOJu0Ywan5dYr+NrClSV8ZT2bMgwJBWSSHKl8muvLRxCdGnYF4ykAlGx oIEBVwp9OgdxhsLSUAXOO6olfpg2T4m+BAnKts7KjZAmOex48TdD2EjlDA8cCa7AG2J6e6rJVAX 20snM8MyL6ZBElKqXMQ5uKtPf2Wcxe+uMY+dKtKwWmOVLt3rDNj1cLs71xA== X-Gm-Gg: ASbGncscQM5Zoge+UyW6HV0e8wwohf6uzSCu+ZAjUntgDD8ZEdH9GHdKaVWbkl6o1s3 Sd459kfaZr2JLuhXfyVxIhsZGUJrZg/A3U7nPTeQT8XP69QuSeaC4GbUCnr8A6Q/B7jtrPki9w9 a4lzRVccJbeRSyaOZNORv04se/fSXcus9kDHr7qh04LCQKBfNp5jgKYagZcGxk2Wmvb5avHX3xj qfnsvVwTOjA8uSlUhwZuZA++pm+3bazMGlqqMDgl7VfhD2p+J3KeE6mLSaL5nmrFPrfrprMSYrA gWXSEHBb1xm7amp4CMcG1jgG/I4mapc0 X-Received: by 2002:ad4:5aab:0:b0:6d4:25c4:e775 with SMTP id 6a1803df08f44-6e1b2179220mr455288516d6.15.1737743735439; Fri, 24 Jan 2025 10:35:35 -0800 (PST) X-Google-Smtp-Source: AGHT+IELidX0vqVGH97qhC21/ZJKfpP5KfU4tM2Z9ZR/iMT9rYWfJHFqO1dJHTy9fhXFv0YsLMUbFg== X-Received: by 2002:ad4:5aab:0:b0:6d4:25c4:e775 with SMTP id 6a1803df08f44-6e1b2179220mr455288186d6.15.1737743735113; Fri, 24 Jan 2025 10:35:35 -0800 (PST) Received: from ?IPV6:2a01:e0a:e10:ef90:343a:68f:2e91:95c? ([2a01:e0a:e10:ef90:343a:68f:2e91:95c]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6e20525b86asm10954346d6.63.2025.01.24.10.35.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 24 Jan 2025 10:35:34 -0800 (PST) Message-ID: <5af65c6f-3bab-4852-84ac-ca8f23123b2e@redhat.com> Date: Fri, 24 Jan 2025 19:35:33 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] vhost-user: Implement an empty VHOST_USER_SEND_RARP command To: Stefano Brivio References: <20250124142137.2296704-1-lvivier@redhat.com> <20250124171016.322d665b@elisabeth> From: Laurent Vivier Autocrypt: addr=lvivier@redhat.com; keydata= xsFNBFYFJhkBEAC2me7w2+RizYOKZM+vZCx69GTewOwqzHrrHSG07MUAxJ6AY29/+HYf6EY2 WoeuLWDmXE7A3oJoIsRecD6BXHTb0OYS20lS608anr3B0xn5g0BX7es9Mw+hV/pL+63EOCVm SUVTEQwbGQN62guOKnJJJfphbbv82glIC/Ei4Ky8BwZkUuXd7d5NFJKC9/GDrbWdj75cDNQx UZ9XXbXEKY9MHX83Uy7JFoiFDMOVHn55HnncflUncO0zDzY7CxFeQFwYRbsCXOUL9yBtqLer Ky8/yjBskIlNrp0uQSt9LMoMsdSjYLYhvk1StsNPg74+s4u0Q6z45+l8RAsgLw5OLtTa+ePM JyS7OIGNYxAX6eZk1+91a6tnqfyPcMbduxyBaYXn94HUG162BeuyBkbNoIDkB7pCByed1A7q q9/FbuTDwgVGVLYthYSfTtN0Y60OgNkWCMtFwKxRaXt1WFA5ceqinN/XkgA+vf2Ch72zBkJL RBIhfOPFv5f2Hkkj0MvsUXpOWaOjatiu0fpPo6Hw14UEpywke1zN4NKubApQOlNKZZC4hu6/ 8pv2t4HRi7s0K88jQYBRPObjrN5+owtI51xMaYzvPitHQ2053LmgsOdN9EKOqZeHAYG2SmRW LOxYWKX14YkZI5j/TXfKlTpwSMvXho+efN4kgFvFmP6WT+tPnwARAQABzSNMYXVyZW50IFZp dmllciA8bHZpdmllckByZWRoYXQuY29tPsLBeAQTAQIAIgUCVgVQgAIbAwYLCQgHAwIGFQgC CQoLBBYCAwECHgECF4AACgkQ8ww4vT8vvjwpgg//fSGy0Rs/t8cPFuzoY1cex4limJQfReLr SJXCANg9NOWy/bFK5wunj+h/RCFxIFhZcyXveurkBwYikDPUrBoBRoOJY/BHK0iZo7/WQkur 6H5losVZtrotmKOGnP/lJYZ3H6OWvXzdz8LL5hb3TvGOP68K8Bn8UsIaZJoeiKhaNR0sOJyI YYbgFQPWMHfVwHD/U+/gqRhD7apVysxv5by/pKDln1I5v0cRRH6hd8M8oXgKhF2+rAOL7gvh jEHSSWKUlMjC7YwwjSZmUkL+TQyE18e2XBk85X8Da3FznrLiHZFHQ/NzETYxRjnOzD7/kOVy gKD/o7asyWQVU65mh/ECrtjfhtCBSYmIIVkopoLaVJ/kEbVJQegT2P6NgERC/31kmTF69vn8 uQyW11Hk8tyubicByL3/XVBrq4jZdJW3cePNJbTNaT0d/bjMg5zCWHbMErUib2Nellnbg6bc 2HLDe0NLVPuRZhHUHM9hO/JNnHfvgiRQDh6loNOUnm9Iw2YiVgZNnT4soUehMZ7au8PwSl4I KYE4ulJ8RRiydN7fES3IZWmOPlyskp1QMQBD/w16o+lEtY6HSFEzsK3o0vuBRBVp2WKnssVH qeeV01ZHw0bvWKjxVNOksP98eJfWLfV9l9e7s6TaAeySKRRubtJ+21PRuYAxKsaueBfUE7ZT 7zfOwU0EVgUmGQEQALxSQRbl/QOnmssVDxWhHM5TGxl7oLNJms2zmBpcmlrIsn8nNz0rRyxT 460k2niaTwowSRK8KWVDeAW6ZAaWiYjLlTunoKwvF8vP3JyWpBz0diTxL5o+xpvy/Q6YU3BN efdq8Vy3rFsxgW7mMSrI/CxJ667y8ot5DVugeS2NyHfmZlPGE0Nsy7hlebS4liisXOrN3jFz asKyUws3VXek4V65lHwB23BVzsnFMn/bw/rPliqXGcwl8CoJu8dSyrCcd1Ibs0/Inq9S9+t0 VmWiQWfQkz4rvEeTQkp/VfgZ6z98JRW7S6l6eophoWs0/ZyRfOm+QVSqRfFZdxdP2PlGeIFM C3fXJgygXJkFPyWkVElr76JTbtSHsGWbt6xUlYHKXWo+xf9WgtLeby3cfSkEchACrxDrQpj+ Jt/JFP+q997dybkyZ5IoHWuPkn7uZGBrKIHmBunTco1+cKSuRiSCYpBIXZMHCzPgVDjk4viP brV9NwRkmaOxVvye0vctJeWvJ6KA7NoAURplIGCqkCRwg0MmLrfoZnK/gRqVJ/f6adhU1oo6 z4p2/z3PemA0C0ANatgHgBb90cd16AUxpdEQmOCmdNnNJF/3Zt3inzF+NFzHoM5Vwq6rc1JP jfC3oqRLJzqAEHBDjQFlqNR3IFCIAo4SYQRBdAHBCzkM4rWyRhuVABEBAAHCwV8EGAECAAkF AlYFJhkCGwwACgkQ8ww4vT8vvjwg9w//VQrcnVg3TsjEybxDEUBm8dBmnKqcnTBFmxN5FFtI WlEuY8+YMiWRykd8Ln9RJ/98/ghABHz9TN8TRo2b6WimV64FmlVn17Ri6FgFU3xNt9TTEChq AcNg88eYryKsYpFwegGpwUlaUaaGh1m9OrTzcQy+klVfZWaVJ9Nw0keoGRGb8j4XjVpL8+2x OhXKrM1fzzb8JtAuSbuzZSQPDwQEI5CKKxp7zf76J21YeRrEW4WDznPyVcDTa+tz++q2S/Bp P4W98bXCBIuQgs2m+OflERv5c3Ojldp04/S4NEjXEYRWdiCxN7ca5iPml5gLtuvhJMSy36gl U6IW9kn30IWuSoBpTkgV7rLUEhh9Ms82VWW/h2TxL8enfx40PrfbDtWwqRID3WY8jLrjKfTd R3LW8BnUDNkG+c4FzvvGUs8AvuqxxyHbXAfDx9o/jXfPHVRmJVhSmd+hC3mcQ+4iX5bBPBPM oDqSoLt5w9GoQQ6gDVP2ZjTWqwSRMLzNr37rJjZ1pt0DCMMTbiYIUcrhX8eveCJtY7NGWNyx FCRkhxRuGcpwPmRVDwOl39MB3iTsRighiMnijkbLXiKoJ5CDVvX5yicNqYJPKh5MFXN1bvsB kmYiStMRbrD0HoY1kx5/VozBtc70OU0EB8Wrv9hZD+Ofp0T3KOr1RUHvCZoLURfFhSQ= In-Reply-To: <20250124171016.322d665b@elisabeth> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: cZBkHXHAxzHlztwqqrRhChMWzanJFxWt9-J5CKNjfII_1737743735 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Message-ID-Hash: S63KADMKTL3ABI7EZKSK3WCGC2NQUN7U X-Message-ID-Hash: S63KADMKTL3ABI7EZKSK3WCGC2NQUN7U X-MailFrom: lvivier@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 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". > >> + * @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, >> }; > Thanks, Laurent