passt/udp_vu.c, branch 2026_05_07.1afd4ed

treewide: Spell ASSERT() as assert()

2026-03-20T20:05:29+00:00

The standard library assert(3), at least with glibc, hits our seccomp
filter and dies with SIGSYS before it's able to print a message, making it
near useless.  Therefore, since 7a8ed9459dfe ("Make assertions actually
useful") we've instead used our own implementation, named ASSERT().

This makes our code look slightly odd though - ASSERT() has the same
overall effect as assert(), it's just a different implementation.  More
importantly this makes it awkward to share code between passt/pasta proper
and things that compile in a more typical environment.  We're going to want
that for our upcoming dynamic configuration tool.

Address this by overriding the standard library's assert() implementation
with our own, instead of giving ours its own name.

The standard assert() is supposed to be omitted if NDEBUG is defined,
which ours doesn't do.  Implement that as well, so ours doesn't
unexpectedly differ.  For the -DNDEBUG case we do this by *not* overriding
assert(), since it will be a no-op anyway.  This requires a few places to
add a #include  to let us compile (albeit with warnings) when
-DNDEBUG.

Signed-off-by: David Gibson 
[sbrivio: Fix some conflicts and missing conversions as a result of
 applying "vu_common: Move iovec management into vu_collect()" first]
Signed-off-by: Stefano Brivio

vu_common: Move iovec management into vu_collect()

2026-03-20T19:05:34+00:00

Previously, callers had to pre-initialize virtqueue elements with iovec
entries using vu_set_element() or vu_init_elem() before calling
vu_collect().  This meant each element owned a fixed, pre-assigned iovec
slot.

Move the iovec array into vu_collect() as explicit parameters (in_sg,
max_in_sg, and in_total), letting it pass the remaining iovec capacity
directly to vu_queue_pop().  A running current_iov counter tracks
consumed entries across elements, so multiple elements share a single
iovec pool.  The optional in_total output parameter reports how many iovec
entries were consumed, allowing callers to track usage across multiple
vu_collect() calls.

This removes vu_set_element() and vu_init_elem() which are no longer
needed, and is a prerequisite for multi-buffer support where a single
virtqueue element can use more than one iovec entry.  For now, callers
assert the current single-iovec-per-element invariant until they are
updated to handle multiple iovecs.

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

iov: Add iov_truncate() helper and use it in vu handlers

2026-03-10T14:26:43+00:00

Add a generic iov_truncate() function that truncates an IO vector to a
given number of bytes, returning the number of iov entries that contain
data after truncation.

Use it in udp_vu_sock_recv() and tcp_vu_sock_recv() to replace the
open-coded truncation logic that adjusted iov entries after recvmsg().
Also convert the direct iov_len assignment in tcp_vu_send_flag() to use
iov_truncate() for consistency.

Add an ASSERT() in tcp_vu_data_from_sock() to quiet the Coverity error:

passt/tcp_vu.c:457:3:
  19. overflow_const: Expression "dlen + hdrlen", where "dlen" is known to
      be equal to -86,  and "hdrlen" is known to be equal to 86, underflows
      the type of "dlen + hdrlen", which is type "unsigned long".

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

vu_common: Always set num_buffers in virtio-net header

2026-03-04T17:50:49+00:00

Legacy virtio used two different header formats: struct virtio_net_hdr
(10 bytes) when VIRTIO_NET_F_MRG_RXBUF was not negotiated, and
struct virtio_net_hdr_mrg_rxbuf (12 bytes) when it was.  The
num_buffers field only existed in the larger header.

Modern virtio (VIRTIO_F_VERSION_1, i.e. virtio 1.0+) always uses the
12-byte struct virtio_net_hdr_mrg_rxbuf header regardless of whether
VIRTIO_NET_F_MRG_RXBUF is negotiated, so num_buffers is always present
in the header.  passt only supports modern virtio and dies if
VIRTIO_F_VERSION_1 is not negotiated (vhost_user.c), and VNET_HLEN is
unconditionally defined as sizeof(struct virtio_net_hdr_mrg_rxbuf).

The virtio specification (v1.1, section 5.1.6) requires that:

  "The device MUST set num_buffers to 1 if VIRTIO_NET_F_MRG_RXBUF has
   not been negotiated."

vu_set_vnethdr() only set num_buffers when VIRTIO_NET_F_MRG_RXBUF was
negotiated.  When it was not, num_buffers was left uninitialised,
violating the spec.

Since vu_collect() already limits buffer collection to a single element
when VIRTIO_NET_F_MRG_RXBUF is not negotiated, num_buffers passed by
callers is guaranteed to be 1 in that case.  We can therefore
unconditionally set num_buffers, which makes the vdev parameter
unnecessary.

Drop the vdev parameter from vu_set_vnethdr() and update all callers.

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

tcp_vu, udp_vu: Fix comment headers for header length functions

2026-02-24T15:31:29+00:00

The comment headers for tcp_vu_hdrlen() and udp_vu_hdrlen() described
the return value as "the size of the header in level 2 frame", but
these functions also include the virtio net header, which is not part
of the L2 frame.

Signed-off-by: Laurent Vivier 
[sbrivio: Rephrased comments a bit further]
Signed-off-by: Stefano Brivio

tcp_vu, udp_vu: Account for virtio net header in minimum frame size

2026-02-24T11:06:03+00:00

In the vhost-user paths, the buffers provided by the virtio queue
include the virtio net header (VNET_HLEN) prepended to the Ethernet
frame. The minimum size checks using ETH_ZLEN must therefore account
for this additional header length, otherwise we underestimate the
minimum buffer size needed.

Use ETH_ZLEN + VNET_HLEN instead of bare ETH_ZLEN in vu_collect()
calls and the corresponding ASSERT() checks.

In tcp_vu_prepare(), revert the ASSERT to just check for hdrlen,
because at that point iov[0].iov_len has been trimmed to the actual
received data size plus headers.

Fixes: 0cb8f9003654 ("tcp, udp: Pad batched frames for vhost-user modes to 60 bytes (802.3 minimum)")
Signed-off-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

virtio: Introduce VNET_HLEN macro for virtio net header length

2026-02-15T01:52:51+00:00

Replace all open-coded sizeof(struct virtio_net_hdr_mrg_rxbuf) with a
VNET_HLEN macro.

Signed-off-by: Laurent Vivier 
Signed-off-by: Stefano Brivio

udp_vu: Discard datagrams when RX virtqueue is not usable

2026-01-10T19:54:13+00:00

During vhost-user device initialization, UDP datagrams may arrive on
listening sockets before the guest has enabled the RX virtqueue.

When this happens, udp_vu_sock_recv() returns 0 without consuming
the datagram from the socket. The caller, udp_sock_fwd(), uses a
while loop with udp_peek_addr() to process pending datagrams. Since
the datagram remains in the socket buffer, udp_peek_addr() keeps
returning data available, causing a busy loop with 100% CPU usage.

To avoid that, we need to discard the data when the virtqueue is not
ready. udp_buf_sock_to_tap() actually does the same as it reads data
with udp_sock_recv() and if fd_tap is not initialized tap_send_frames()
drops them.

Fixes: 28997fcb29b5 ("vhost-user: add vhost-user")
Link: https://bugs.passt.top/show_bug.cgi?id=185
Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio

tcp, udp: Pad batched frames for vhost-user modes to 60 bytes (802.3 minimum)

2025-12-08T03:47:46+00:00

For both TCP and UDP, instead of just expecting the first provided
buffer to be large enough to contain the headers we need (from 42
bytes for UDP data over IPv4 to 82 bytes for TCP with options over
IPv6), change that assumption to make sure that buffers are anyway
at least ETH_ZLEN-sized buffers (60 bytes).

This looks reasonable because there are no known vhost-user
hypervisor implementations that would give us smaller buffers than
that, and we would anyway hit an assertion failure with IPv6 if we
ever had less than 60 bytes per buffer.

At this point, all we need to do is to pad the first (and only)
buffer, should data and headers use less than that.

Link: https://bugs.passt.top/show_bug.cgi?id=166
Signed-off-by: Stefano Brivio 
Reviewed-by: David Gibson

udp_vu: Pass virtqueue pointer to udp_vu_sock_recv()

2025-09-09T19:14:32+00:00

Pass the virtqueue pointer to udp_vu_sock_recv() to enable proper
queue selection for multiqueue support. This ensures that received
packets are processed on the same virtqueue as the caller.

Signed-off-by: Laurent Vivier 
Reviewed-by: David Gibson 
Signed-off-by: Stefano Brivio