- dev - passt

[PATCH v3 0/3] Decouple iovec management from virtqueue elements
by Laurent Vivier 21 Mar '26

21 Mar '26

This series prepares the vhost-user path for multi-buffer support, where a single virtqueue element can use more than one iovec entry. Currently, iovec arrays are tightly coupled to virtqueue elements: callers must pre-initialize each element's in_sg/out_sg pointers before calling vu_queue_pop(), and each element is assumed to own exactly one iovec slot. This makes it impossible for a single element to span multiple iovec entries, which is needed for UDP multi-buffer reception. The series decouples iovec storage from elements in three patches: - Patch 1 passes iovec arrays as separate parameters to vu_queue_pop() and vu_queue_map_desc(), so the caller controls where descriptors are mapped rather than reading them from pre-initialized element fields. - Patch 2 passes the actual remaining out_sg capacity to vu_queue_pop() in vu_handle_tx() instead of a fixed per-element constant, enabling dynamic iovec allocation. - Patch 3 moves iovec pool management into vu_collect(), which now accepts the iovec array and tracks consumed entries across elements with a running counter. This removes vu_set_element() and vu_init_elem() entirely. Callers that still assume one iovec per element assert this invariant explicitly until they are updated for multi-buffer. The follow-up udp-iov_vu series builds on this to implement actual multi-buffer support in the UDP vhost-user path. v3: - rebase and add David's R-b - fix coding style (if) - rename in_num to in_total v2: - in patch 3, use iov_used in iov_truncate() rather than elem_cnt as vu_collect() is now providing the number of iovec collected. Laurent Vivier (3): virtio: Pass iovec arrays as separate parameters to vu_queue_pop() vu_handle_tx: Pass actual remaining out_sg capacity to vu_queue_pop() vu_common: Move iovec management into vu_collect() tcp_vu.c | 25 +++++++++------- udp_vu.c | 21 ++++++++------ virtio.c | 29 ++++++++++++++----- virtio.h | 4 ++- vu_common.c | 82 ++++++++++++++++++++++++----------------------------- vu_common.h | 22 ++------------ 6 files changed, 91 insertions(+), 92 deletions(-) -- 2.53.0

3 5

[RFC PATCH] tcp: Replace send buffer boost with EPOLLOUT monitoring
by Yumei Huang 20 Mar '26

20 Mar '26

Currently we use the SNDBUF boost mechanism to force TCP auto-tuning. However, it doesn't always work, and sometimes causes a lot of retransmissions. As a result, the throughput suffers. This patch replaces it with monitoring EPOLLOUT when sendmsg() failure (with EAGAIN and EWOULDBLOCK) and partial sends occur. Tested with iperf3 inside pasta: throughput is now comparable to running iperf3 directly on the host without pasta. However, retransmissions can still be elevated when RTT >= 50ms. For example, when RTT is between 200ms and 500ms, retransmission count varies from 30 to 120 in roughly 80% of test runs. Link: https://bugs.passt.top/show_bug.cgi?id=138 Suggested-by: Stefano Brivio <sbrivio(a)redhat.com> Signed-off-by: Yumei Huang <yuhuang(a)redhat.com> --- tcp.c | 57 +++++++++++++++++---------------------------------------- 1 file changed, 17 insertions(+), 40 deletions(-) diff --git a/tcp.c b/tcp.c index 9d91c3c..f7e3932 100644 --- a/tcp.c +++ b/tcp.c @@ -353,13 +353,6 @@ enum { #define LOW_RTT_TABLE_SIZE 8 #define LOW_RTT_THRESHOLD 10 /* us */ -/* Parameters to temporarily exceed sending buffer to force TCP auto-tuning */ -#define SNDBUF_BOOST_BYTES_RTT_LO 2500 /* B * s: no boost until here */ -/* ...examples: 5 MB sent * 500 ns RTT, 250 kB * 10 ms, 8 kB * 300 ms */ -#define SNDBUF_BOOST_FACTOR 150 /* % */ -#define SNDBUF_BOOST_BYTES_RTT_HI 6000 /* apply full boost factor */ -/* 12 MB sent * 500 ns RTT, 600 kB * 10 ms, 20 kB * 300 ms */ - /* Ratio of buffer to bandwidth * delay product implying interactive traffic */ #define SNDBUF_TO_BW_DELAY_INTERACTIVE /* > */ 20 /* (i.e. < 5% of buffer) */ @@ -1023,35 +1016,6 @@ size_t tcp_fill_headers(const struct ctx *c, struct tcp_tap_conn *conn, return MAX(l3len + sizeof(struct ethhdr), ETH_ZLEN); } -/** - * tcp_sndbuf_boost() - Calculate limit of sending buffer to force auto-tuning - * @conn: Connection pointer - * @tinfo: tcp_info from kernel, must be pre-fetched - * - * Return: increased sending buffer to use as a limit for advertised window - */ -static unsigned long tcp_sndbuf_boost(const struct tcp_tap_conn *conn, - const struct tcp_info_linux *tinfo) -{ - unsigned long bytes_rtt_product; - - if (!bytes_acked_cap) - return SNDBUF_GET(conn); - - /* This is *not* a bandwidth-delay product, but it's somewhat related: - * as we send more data (usually at the beginning of a connection), we - * try to make the sending buffer progressively grow, with the RTT as a - * factor (longer delay, bigger buffer needed). - */ - bytes_rtt_product = (long long)tinfo->tcpi_bytes_acked * - tinfo->tcpi_rtt / 1000 / 1000; - - return clamped_scale(SNDBUF_GET(conn), bytes_rtt_product, - SNDBUF_BOOST_BYTES_RTT_LO, - SNDBUF_BOOST_BYTES_RTT_HI, - SNDBUF_BOOST_FACTOR); -} - /** * tcp_update_seqack_wnd() - Update ACK sequence and window to guest/tap * @c: Execution context @@ -1174,8 +1138,6 @@ int tcp_update_seqack_wnd(const struct ctx *c, struct tcp_tap_conn *conn, if ((int)sendq > SNDBUF_GET(conn)) /* Due to memory pressure? */ limit = 0; - else if ((int)tinfo->tcpi_snd_wnd > SNDBUF_GET(conn)) - limit = tcp_sndbuf_boost(conn, tinfo) - (int)sendq; else limit = SNDBUF_GET(conn) - (int)sendq; @@ -2050,14 +2012,28 @@ eintr: if (errno == EAGAIN || errno == EWOULDBLOCK) { tcp_send_flag(c, conn, ACK | DUP_ACK); + uint32_t events = tcp_conn_epoll_events(conn->events, + conn->flags); + events |= EPOLLOUT; + if (flow_epoll_set(&conn->f, EPOLL_CTL_MOD, events, + conn->sock, !TAPSIDE(conn)) < 0) + debug("Failed to add EPOLLOUT"); return p->count - idx; - } return -1; } - if (n < (int)(seq_from_tap - conn->seq_from_tap)) + if (n < (int)(seq_from_tap - conn->seq_from_tap)) { partial_send = 1; + uint32_t events = tcp_conn_epoll_events(conn->events, + conn->flags); + events |= EPOLLOUT; + if (flow_epoll_set(&conn->f, EPOLL_CTL_MOD, events, conn->sock, + !TAPSIDE(conn)) < 0) + debug("Failed to add EPOLLOUT"); + } else { + tcp_epoll_ctl(conn); + } conn->seq_from_tap += n; @@ -2661,6 +2637,7 @@ void tcp_sock_handler(const struct ctx *c, union epoll_ref ref, tcp_data_from_sock(c, conn); if (events & EPOLLOUT) { + tcp_epoll_ctl(conn); if (tcp_update_seqack_wnd(c, conn, false, NULL)) tcp_send_flag(c, conn, ACK); } -- 2.53.0

1 0

[PATCH v2 04/15] fwd: Move selecting correct scan bitmap into fwd_sync_one()
by David Gibson 19 Mar '26

19 Mar '26

Currently fwd_listen_sync_() determines which of the two port scanned bitmaps is the correct one for a rule before passing it into fwd_sync_one(). However, fwd_sync_one() is already looking at the rule internals so is better placed to do this. Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- fwd.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/fwd.c b/fwd.c index f3b4bf2a..a306b409 100644 --- a/fwd.c +++ b/fwd.c @@ -508,16 +508,18 @@ void fwd_rules_print(const struct fwd_table *fwd) * @fwd: Forwarding table * @rule: Forwarding rule * @pif: Interface to create listening sockets for - * @scanmap: Bitmap of ports to listen for on FWD_SCAN entries + * @tcp: Bitmap of TCP ports to listen for on FWD_SCAN entries + * @udp: Bitmap of UDP ports to listen for on FWD_SCAN entries * * Return: 0 on success, -1 on failure */ static int fwd_sync_one(const struct ctx *c, const struct fwd_table *fwd, const struct fwd_rule *rule, uint8_t pif, - const uint8_t *scanmap) + const uint8_t *tcp, const uint8_t *udp) { const union inany_addr *addr = fwd_rule_addr(rule); const char *ifname = rule->ifname; + const uint8_t *map = NULL; bool bound_one = false; unsigned port, idx; @@ -528,12 +530,19 @@ static int fwd_sync_one(const struct ctx *c, const struct fwd_table *fwd, idx = rule - fwd->rules; assert(idx < MAX_FWD_RULES); - assert(!(rule->flags & FWD_SCAN && !scanmap)); - + + if (rule->flags & FWD_SCAN) { + if (rule->proto == IPPROTO_TCP) + map = tcp; + else if (rule->proto == IPPROTO_UDP) + map = udp; + assert(map); + } + for (port = rule->first; port <= rule->last; port++) { int fd = rule->socks[port - rule->first]; - if ((rule->flags & FWD_SCAN) && !bitmap_isset(scanmap, port)) { + if (map && !bitmap_isset(map, port)) { /* We don't want to listen on this port */ if (fd >= 0) { /* We already are, so stop */ @@ -619,15 +628,8 @@ static int fwd_listen_sync_(void *arg) ns_enter(a->c); for (i = 0; i < a->fwd->count; i++) { - const uint8_t *scanmap = NULL; - - if (a->fwd->rules[i].proto == IPPROTO_TCP) - scanmap = a->tcpmap; - else if (a->fwd->rules[i].proto == IPPROTO_UDP) - scanmap = a->udpmap; - a->ret = fwd_sync_one(a->c, a->fwd, &a->fwd->rules[i], - a->pif, scanmap); + a->pif, a->tcpmap, a->udpmap); if (a->ret < 0) break; } -- 2.53.0

1 0

[PATCH v2 03/15] serialise: Add helpers for serialising unsigned integers
by David Gibson 19 Mar '26

19 Mar '26

Add helpers to serialise/deserialise unsigned integers, handling endian conversion so that the stream format is consistent regardless of host endiannness. Currently we only use this on one place: sending the number of flows during migration. We're going to have more use for this as we add dynamic configuration updates, so these will become more useful. For now we only need a 32-bit version, however define the functions with a macro so we can easily add other integer widths when we need them. Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- flow.c | 10 ++++------ serialise.c | 35 +++++++++++++++++++++++++++++++++++ serialise.h | 7 +++++++ 3 files changed, 46 insertions(+), 6 deletions(-) diff --git a/flow.c b/flow.c index 7d3c5ae6..81333dbc 100644 --- a/flow.c +++ b/flow.c @@ -1135,10 +1135,9 @@ int flow_migrate_source(struct ctx *c, const struct migrate_stage *stage, count++; } - count = htonl(count); - if (sewrite_var(fd, &count)) { + if (sewrite_u32(fd, count)) { rc = errno; - err_perror("Can't send flow count (%u)", ntohl(count)); + err_perror("Can't send flow count (%u)", count); return flow_migrate_source_rollback(c, FLOW_MAX, rc); } @@ -1151,7 +1150,7 @@ int flow_migrate_source(struct ctx *c, const struct migrate_stage *stage, debug("Stop listen()s"); fwd_listen_close(&c->fwd_in); - debug("Sending %u flows", ntohl(count)); + debug("Sending %u flows", count); if (!count) return 0; @@ -1221,10 +1220,9 @@ int flow_migrate_target(struct ctx *c, const struct migrate_stage *stage, (void)stage; - if (seread_var(fd, &count)) + if (seread_u32(fd, &count)) return errno; - count = ntohl(count); debug("Receiving %u flows", count); if (!count) diff --git a/serialise.c b/serialise.c index 68054722..098ae35c 100644 --- a/serialise.c +++ b/serialise.c @@ -13,7 +13,9 @@ */ #include <assert.h> +#include <endian.h> #include <errno.h> +#include <stdint.h> #include <unistd.h> #include "serialise.h" @@ -86,3 +88,36 @@ int sewrite_buf(int fd, const void *buf, size_t len) } return 0; } + +/** + * seread_uXXX() - Receive a uXXX value from an fd + * @fd: File descriptor to read from + * @valp: Pointer to variable to update with read value + * + * Return: 0 on success, -1 on error + */ +/** + * sewrite_uXXX() - Send a uXXX value to an fd + * @fd: File descriptor to write to + * @val: Value to send + * + * Return: 0 on success, -1 on error + */ +#define SERIALISE_UINT(bits) \ + int seread_u##bits(int fd, uint##bits##_t *val) \ + { \ + uint##bits##_t beval; \ + if (seread_var(fd, &beval) < 0) \ + return -1; \ + *val = be##bits##toh(beval); \ + return 0; \ + } \ + int sewrite_u##bits(int fd, uint##bits##_t val) \ + { \ + uint##bits##_t beval = htobe##bits(val); \ + return sewrite_var(fd, &beval); \ + } + +SERIALISE_UINT(32) + +#undef SERIALISE_UNIT diff --git a/serialise.h b/serialise.h index ec95287f..f2e0aa8d 100644 --- a/serialise.h +++ b/serialise.h @@ -7,6 +7,7 @@ #define SERIALISE_H #include <stddef.h> +#include <stdint.h> int seread_buf(int fd, void *buf, size_t len); int sewrite_buf(int fd, const void *buf, size_t len); @@ -14,4 +15,10 @@ int sewrite_buf(int fd, const void *buf, size_t len); #define seread_var(fd_, var_) (seread_buf((fd_), (var_), sizeof(*(var_)))) #define sewrite_var(fd_, var_) (sewrite_buf((fd_), (var_), sizeof(*(var_)))) +#define SERIALISE_UINT_DECL(bits) \ + int seread_u##bits(int fd, uint##bits##_t *val); \ + int sewrite_u##bits(int fd, uint##bits##_t val); + +SERIALISE_UINT_DECL(32) + #endif /* _SERIALISE_H */ -- 2.53.0

1 0

[PATCH v2 0/3] Decouple iovec management from virtqueue elements
by Laurent Vivier 18 Mar '26

18 Mar '26

This series prepares the vhost-user path for multi-buffer support, where a single virtqueue element can use more than one iovec entry. Currently, iovec arrays are tightly coupled to virtqueue elements: callers must pre-initialize each element's in_sg/out_sg pointers before calling vu_queue_pop(), and each element is assumed to own exactly one iovec slot. This makes it impossible for a single element to span multiple iovec entries, which is needed for UDP multi-buffer reception. The series decouples iovec storage from elements in three patches: - Patch 1 passes iovec arrays as separate parameters to vu_queue_pop() and vu_queue_map_desc(), so the caller controls where descriptors are mapped rather than reading them from pre-initialized element fields. - Patch 2 passes the actual remaining out_sg capacity to vu_queue_pop() in vu_handle_tx() instead of a fixed per-element constant, enabling dynamic iovec allocation. - Patch 3 moves iovec pool management into vu_collect(), which now accepts the iovec array and tracks consumed entries across elements with a running counter. This removes vu_set_element() and vu_init_elem() entirely. Callers that still assume one iovec per element assert this invariant explicitly until they are updated for multi-buffer. The follow-up udp-iov_vu series builds on this to implement actual multi-buffer support in the UDP vhost-user path. v2: - in patch 3, use iov_used in iov_truncate() rather than elem_cnt as vu_collect() is now providing the number of iovec collected. Laurent Vivier (3): virtio: Pass iovec arrays as separate parameters to vu_queue_pop() vu_handle_tx: Pass actual remaining out_sg capacity to vu_queue_pop() vu_common: Move iovec management into vu_collect() tcp_vu.c | 25 +++++++++------- udp_vu.c | 21 ++++++++------ virtio.c | 29 ++++++++++++++----- virtio.h | 4 ++- vu_common.c | 83 ++++++++++++++++++++++++----------------------------- vu_common.h | 22 ++------------ 6 files changed, 92 insertions(+), 92 deletions(-) -- 2.53.0

3 18

[PATCH 0/5] RFC: Stub dynamic update implementation
by David Gibson 18 Mar '26

18 Mar '26

I've taken Stefano's draft implementation of dynamic updates, and polished it up to have a stub implementation of the dynamic update protocol. So far it doesn't actually do anything, beyond establishing the connection and checking versions. I'm continuing to work on the actual guts of it. Patches 1..3/5 are trivial cleanups I happened across while working on this. Feel free to apply if you like. 4/5 clears up a more specific problem that caused problems sharing code between client and server. 5/5 is the implementation proper. David Gibson (5): Makefile: Use $^ to avoid duplication in static checker rules doc: Fix formatting of (DEPRECATED) notes in man page pif: Remove unused PIF_NAMELEN treewide: Spell ASSERT() as assert() pesto: Introduce stub configuration interface and tool .gitignore | 2 + Makefile | 36 +++++++----- conf.c | 154 +++++++++++++++++++++++++++++++++++++++++++++++++-- conf.h | 2 + epoll_type.h | 4 ++ flow.c | 80 +++++++++++++------------- flow_table.h | 2 +- fwd.c | 14 ++--- icmp.c | 14 ++--- inany.h | 4 +- iov.c | 2 +- isolation.c | 2 +- lineread.c | 4 +- netlink.c | 2 +- packet.c | 4 +- passt.1 | 9 ++- passt.c | 10 +++- passt.h | 6 ++ pesto.1 | 47 ++++++++++++++++ pesto.c | 111 +++++++++++++++++++++++++++++++++++++ pesto.h | 34 ++++++++++++ pesto_util.c | 62 +++++++++++++++++++++ pesto_util.h | 19 +++++++ pif.c | 4 +- pif.h | 2 - tap.c | 6 +- tcp.c | 24 ++++---- tcp_splice.c | 10 ++-- tcp_vu.c | 8 +-- udp.c | 22 ++++---- udp_flow.c | 4 +- udp_vu.c | 4 +- util.c | 42 +------------- util.h | 15 ++--- vhost_user.c | 8 +-- virtio.c | 4 +- vu_common.c | 4 +- 37 files changed, 599 insertions(+), 182 deletions(-) create mode 100644 pesto.1 create mode 100644 pesto.c create mode 100644 pesto.h create mode 100644 pesto_util.c create mode 100644 pesto_util.h -- 2.53.0

2 15

Re: [PATCH v2 3/3] vu_common: Move iovec management into vu_collect()
by Stefano Brivio 17 Mar '26

17 Mar '26

On Tue, 17 Mar 2026 17:30:32 +0100 Laurent Vivier <lvivier(a)redhat.com> wrote: > On 3/17/26 16:23, Stefano Brivio wrote: > > On Tue, 17 Mar 2026 08:25:49 +0100 > > Laurent Vivier <lvivier(a)redhat.com> wrote: > > > >> On 3/17/26 03:40, David Gibson wrote: > >>> On Fri, Mar 13, 2026 at 07:26:18PM +0100, Laurent Vivier wrote: > >>>> 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_num), 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_num 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 <lvivier(a)redhat.com> > >>> > >>> Reviewed-by: David Gibson <david(a)gibson.dropbear.id.au> > >>> > >>> Couple of thoughts on possible polish below. > >>> > >>> [snip] > >>>> /** > >>>> * vu_collect() - collect virtio buffers from a given virtqueue > >>>> * @vdev: vhost-user device > >>>> * @vq: virtqueue to collect from > >>>> - * @elem: Array of virtqueue element > >>>> - * each element must be initialized with one iovec entry > >>>> - * in the in_sg array. > >>>> + * @elem: Array of @max_elem virtqueue elements > >>>> * @max_elem: Number of virtqueue elements in the array > >>>> + * @in_sg: Incoming iovec array for device-writable descriptors > >>>> + * @max_in_sg: Maximum number of entries in @in_sg > >>>> + * @in_num: Number of collected entries from @in_sg (output) > >>>> * @size: Maximum size of the data in the frame > >>>> * @collected: Collected buffer length, up to @size, set on return > >>>> * > >>>> @@ -80,20 +67,21 @@ void vu_init_elem(struct vu_virtq_element *elem, struct iovec *iov, int elem_cnt > >>>> */ > >>>> int vu_collect(const struct vu_dev *vdev, struct vu_virtq *vq, > >>>> struct vu_virtq_element *elem, int max_elem, > >>>> + struct iovec *in_sg, size_t max_in_sg, size_t *in_num, > >>>> size_t size, size_t *collected) > >>>> { > >>>> size_t current_size = 0; > >>>> + size_t current_iov = 0; > >>>> int elem_cnt = 0; > >>>> > >>>> - while (current_size < size && elem_cnt < max_elem) { > >>>> - struct iovec *iov; > >>>> + while (current_size < size && elem_cnt < max_elem && > >>>> + current_iov < max_in_sg) { > >>>> int ret; > >>>> > >>>> ret = vu_queue_pop(vdev, vq, &elem[elem_cnt], > >>>> - elem[elem_cnt].in_sg, > >>>> - elem[elem_cnt].in_num, > >>>> - elem[elem_cnt].out_sg, > >>>> - elem[elem_cnt].out_num); > >>>> + &in_sg[current_iov], > >>>> + max_in_sg - current_iov, > >>>> + NULL, 0); > >>>> if (ret < 0) > >>>> break; > >>>> > >>>> @@ -103,18 +91,22 @@ int vu_collect(const struct vu_dev *vdev, struct vu_virtq *vq, > >>>> break; > >>>> } > >>>> > >>>> - iov = &elem[elem_cnt].in_sg[0]; > >>>> - > >>>> - if (iov->iov_len > size - current_size) > >>>> - iov->iov_len = size - current_size; > >>>> + elem[elem_cnt].in_num = iov_truncate(elem[elem_cnt].in_sg, > >>>> + elem[elem_cnt].in_num, > >>>> + size - current_size); > >>> > >>> Will elem[].in_num always end up with the same value as the @in_num > >>> parameter? If so, do we need the explicit parameter? > >> > >> @in_num parameter of vu_collect()? > >> > >> @in_num is the sum of all elem[].in_num, it can be computed by the caller function from > >> elem, but it is simpler to return it as we need to compute it in the loop. > > > > I'm not sure I understood the point of David's comment here, and this > > explanation makes sense to me now, but it took me a bit to figure that > > out. > > > > Could it be that @in_num is a bit confusing as it has "in" and "num" in > > it, but it's actually an output representing how many "in" entries we > > used/need? > > For an element, *ìn_*num is the number of *in_*sg we have read from the ring for an element. > > It's virtio semantic, so *in_* means sg going *in* the guest. Sure, that's fair, and: > For *out_*sg we have *out_*num. ...we certainly can't call it "out_" because of that. My problem is that "num" together with that becomes quite unspecific. > > What if we rename it to @in_used or @in_collected? > > The idea was to keep the same name as in the element. But we can change this to @in_used. Oh, I see now. Maybe let's wait for David to comment, as maybe he was confused by the whole naming as well (my guess at least). -- Stefano

1 0

[PATCH v3 0/8] vhost-user,udp: Handle multiple iovec entries per virtqueue element
by Laurent Vivier 16 Mar '26

16 Mar '26

Some virtio-net drivers (notably iPXE) provide descriptors where the vnet header and the frame payload are in separate buffers, resulting in two iovec entries per virtqueue element. Currently, the RX (host to guest) path assumes a single iovec per element, which triggers: ASSERTION FAILED in virtqueue_map_desc (virtio.c:403): num_sg < max_num_sg This series reworks the UDP vhost-user receive path to support multiple iovec entries per element, fixing the iPXE crash. This series only addresses the UDP path. TCP vhost-user will be updated to use multi-iov elements in a subsequent series. v3: - include the series "Decouple iovec management from virtqueues elements" - because of this series, drop: "vu_common: Accept explicit iovec counts in vu_set_element()" "vu_common: Accept explicit iovec count per element in vu_init_elem()" "vu_common: Prepare to use multibuffer with guest RX" "vhost-user,udp: Use 2 iovec entries per element" - drop "vu_common: Pass iov_tail to vu_set_vnethdr()" as the specs insures a buffer is big enough to contain vnet header - introduce "with_header()" and merge "udp: Pass iov_tail to udp_update_hdr4()/udp_update_hdr6()" and "udp_vu: Use iov_tail in udp_vu_prepare()" to use it v2: - add iov_truncate(), iov_memset() - remove iov_tail_truncate() and iov_tail_zero_end() - manage 802.3 minimum frame size Laurent Vivier (8): virtio: Pass iovec arrays as separate parameters to vu_queue_pop() vu_handle_tx: Pass actual remaining out_sg capacity to vu_queue_pop() vu_common: Move iovec management into vu_collect() vhost-user: Centralise Ethernet frame padding in vu_collect(), vu_pad() and vu_flush() udp_vu: Use iov_tail to manage virtqueue buffers udp_vu: Move virtqueue management from udp_vu_sock_recv() to its caller iov: Add IOV_PUT_HEADER() and with_header() to write header data back to iov_tail udp: Pass iov_tail to udp_update_hdr4()/udp_update_hdr6() iov.c | 47 +++++++++++ iov.h | 27 ++++++- tcp_vu.c | 46 +++++------ udp.c | 129 ++++++++++++++++-------------- udp_internal.h | 6 +- udp_vu.c | 207 +++++++++++++++++++++++++------------------------ virtio.c | 29 +++++-- virtio.h | 4 +- vu_common.c | 149 ++++++++++++++++++++--------------- vu_common.h | 24 +----- 10 files changed, 385 insertions(+), 283 deletions(-) -- 2.53.0

1 8

[PATCH 0/3] Decouple iovec management from virtqueue elements
by Laurent Vivier 13 Mar '26

13 Mar '26

This series prepares the vhost-user path for multi-buffer support, where a single virtqueue element can use more than one iovec entry. Currently, iovec arrays are tightly coupled to virtqueue elements: callers must pre-initialize each element's in_sg/out_sg pointers before calling vu_queue_pop(), and each element is assumed to own exactly one iovec slot. This makes it impossible for a single element to span multiple iovec entries, which is needed for UDP multi-buffer reception. The series decouples iovec storage from elements in three patches: - Patch 1 passes iovec arrays as separate parameters to vu_queue_pop() and vu_queue_map_desc(), so the caller controls where descriptors are mapped rather than reading them from pre-initialized element fields. - Patch 2 passes the actual remaining out_sg capacity to vu_queue_pop() in vu_handle_tx() instead of a fixed per-element constant, enabling dynamic iovec allocation. - Patch 3 moves iovec pool management into vu_collect(), which now accepts the iovec array and tracks consumed entries across elements with a running counter. This removes vu_set_element() and vu_init_elem() entirely. Callers that still assume one iovec per element assert this invariant explicitly until they are updated for multi-buffer. The follow-up udp-iov_vu series builds on this to implement actual multi-buffer support in the UDP vhost-user path. Laurent Vivier (3): virtio: Pass iovec arrays as separate parameters to vu_queue_pop() vu_handle_tx: Pass actual remaining out_sg capacity to vu_queue_pop() vu_common: Move iovec management into vu_collect() tcp_vu.c | 23 ++++++++------- udp_vu.c | 21 ++++++++------ virtio.c | 29 ++++++++++++++----- virtio.h | 4 ++- vu_common.c | 83 ++++++++++++++++++++++++----------------------------- vu_common.h | 22 ++------------ 6 files changed, 91 insertions(+), 91 deletions(-) -- 2.53.0

1 3

[PATCH v2 00/13] vhost-user,udp: Handle multiple iovec entries per virtqueue element
by Laurent Vivier 12 Mar '26

12 Mar '26

Some virtio-net drivers (notably iPXE) provide descriptors where the vnet header and the frame payload are in separate buffers, resulting in two iovec entries per virtqueue element. Currently, the RX (host to guest) path assumes a single iovec per element, which triggers: ASSERTION FAILED in virtqueue_map_desc (virtio.c:403): num_sg < max_num_sg This series reworks the UDP vhost-user receive path to support multiple iovec entries per element, fixing the iPXE crash. This series only addresses the UDP path. TCP vhost-user will be updated to use multi-iov elements in a subsequent series. v2: - add iov_truncate(), iov_memset() - remove iov_tail_truncate() and iov_tail_zero_end() - manage 802.3 minimum frame size Laurent Vivier (13): iov: Add iov_truncate() helper and use it in vu handlers vhost-user: Centralise 802.3 frame padding in vu_collect() and vu_flush() vhost-user: Use ARRAY_SIZE(elem) instead of VIRTQUEUE_MAX_SIZE udp_vu: Use iov_tail to manage virtqueue buffers udp_vu: Move virtqueue management from udp_vu_sock_recv() to its caller iov: Add IOV_PUT_HEADER() to write header data back to iov_tail udp: Pass iov_tail to udp_update_hdr4()/udp_update_hdr6() udp_vu: Use iov_tail in udp_vu_prepare() vu_common: Pass iov_tail to vu_set_vnethdr() vu_common: Accept explicit iovec counts in vu_set_element() vu_common: Accept explicit iovec count per element in vu_init_elem() vu_common: Prepare to use multibuffer with guest RX vhost-user,udp: Use 2 iovec entries per element iov.c | 69 +++++++++++++++++ iov.h | 17 ++++- tcp_vu.c | 73 +++++++++--------- udp.c | 72 +++++++++--------- udp_internal.h | 10 ++- udp_vu.c | 197 +++++++++++++++++++++++++------------------------ vu_common.c | 127 +++++++++++++++++++------------ vu_common.h | 20 +++-- 8 files changed, 356 insertions(+), 229 deletions(-) -- 2.53.0

2 27