From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alyssa Ross <hi@alyssa.is>
Cc: qemu-devel@nongnu.org, Yureka Lilian <yureka@cyberchaos.dev>,
Stefano Garzarella <sgarzare@redhat.com>
Subject: Re: [PATCH] vhost-user.rst: clarify when FDs can be sent
Date: Sun, 9 Nov 2025 03:55:50 -0500 [thread overview]
Message-ID: <20251109035512-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20251106192105.3456755-1-hi@alyssa.is>
On Thu, Nov 06, 2025 at 08:21:05PM +0100, Alyssa Ross wrote:
> Previously the spec did not say where in a message the FDs should be
> sent. As I understand it, FDs transferred in ancilliary data will
ancillary, actually
> always be received along with the first byte of the data they were
> sent with, so we should define which byte that is. Going by both
> libvhost-user in QEMU and the rust-vmm crate, that byte is the first
> byte of the message header. This is important to specify because it
> would make back-end implementation significantly more complicated if
> receiving file descriptors in the middle of a message had to be
> handled.
>
> Signed-off-by: Alyssa Ross <hi@alyssa.is>
> ---
> docs/interop/vhost-user.rst | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/docs/interop/vhost-user.rst b/docs/interop/vhost-user.rst
> index 2e50f2ddfa..93a9c8df2b 100644
> --- a/docs/interop/vhost-user.rst
> +++ b/docs/interop/vhost-user.rst
> @@ -411,6 +411,13 @@ in the ancillary data:
> * ``VHOST_USER_SET_INFLIGHT_FD`` (if ``VHOST_USER_PROTOCOL_F_INFLIGHT_SHMFD``)
> * ``VHOST_USER_SET_DEVICE_STATE_FD``
>
> +When sending file descriptors in ancilliary data, *front-end* should
ancillary, here too
> +associate the ancilliary data with a ``sendmsg`` operation (or
> +equivalent) that sends bytes starting with the first byte of the
> +message header. *back-end* can therefore expect that file descriptors
> +will only be received in the first ``recvmsg`` operation for a message
> +header.
> +
> If *front-end* is unable to send the full message or receives a wrong
> reply it will close the connection. An optional reconnection mechanism
> can be implemented.
>
> base-commit: 917ac07f9aef579b9538a81d45f45850aba42906
> --
> 2.51.0
prev parent reply other threads:[~2025-11-09 8:57 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-06 19:21 [PATCH] vhost-user.rst: clarify when FDs can be sent Alyssa Ross
2025-11-09 8:55 ` Michael S. Tsirkin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251109035512-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=hi@alyssa.is \
--cc=qemu-devel@nongnu.org \
--cc=sgarzare@redhat.com \
--cc=yureka@cyberchaos.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.