March 2026 - dev

[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

[PATCH v2 0/9] Unify TCP and UDP forwarding tables
by David Gibson 12 Mar '26

12 Mar '26

This will make the dynamic update protocol and future forwarding extensions easier. Along the way I spotted a number of other minor faults, and have fixed those too. Changes in v2: * Several documentation and whitespace changes * Updated MAX_LISTEN_SOCKS since it's now per pif but not per protocol * Actually removed old TCP tables, overlooked before * Added 2 additional cleanup patches David Gibson (9): conf, fwd: Make overall forwarding mode local to conf path tcp: Remove stale description of port_to_tap field fwd: Don't initialise unused port bitmaps Fix misnamed field in struct ctx comments fwd: Split forwarding table from port scanning state fwd: Unify TCP and UDP forwarding tables fwd: Always open /proc/net{tcp,tcp6,udp,udp6} in pasta mode conf: Don't defer handling of --dns option conf: Parse all forwarding options at the same time conf.c | 225 ++++++++++++++++++++++++++------------------------ flow.c | 25 ++---- fwd.c | 249 ++++++++++++++++++++++++++++++++++---------------------- fwd.h | 67 +++++++-------- passt.c | 3 + passt.h | 7 +- tcp.c | 8 +- tcp.h | 9 +- udp.c | 9 +- udp.h | 8 +- 10 files changed, 331 insertions(+), 279 deletions(-) -- 2.53.0

2 11

[PATCH] netlink: Allow NULL to be passed as addr parameter to nl_addr_get (again)
by David Gibson 11 Mar '26

11 Mar '26

A recent fix to nl_addr_get() unfortunately introduced a different problem. 251e676bd0bf removed a test if @addr was non-NULL. conf_ip6() relied on being able to pass NULL in order to update the link-local address without updating the main address (because it was already set by the user). This means that 'pasta -a 2001:db8::1' will SEGV. Reverse the incorrect part of the change to fix this. Fixes: 251e676bd0bf ("netlink: Return prefix length for IPv6 addresses in nl_addr_get()") Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- netlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/netlink.c b/netlink.c index ee9a6b16..e07b47f4 100644 --- a/netlink.c +++ b/netlink.c @@ -788,7 +788,7 @@ int nl_addr_get(int s, unsigned int ifi, sa_family_t af, (af == AF_INET6 && rta->rta_type != IFA_ADDRESS)) continue; - if (ifa->ifa_prefixlen > prefix_max && + if (ifa->ifa_prefixlen > prefix_max && addr && (af == AF_INET || ifa->ifa_scope < RT_SCOPE_LINK)) { memcpy(addr, RTA_DATA(rta), RTA_PAYLOAD(rta)); -- 2.53.0

2 1

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

11 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. Laurent Vivier (12): iov: Add iov_tail_truncate() and iov_tail_zero_end() 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 | 58 +++++++++++++++ iov.h | 16 +++- tcp_vu.c | 18 +++-- udp.c | 65 ++++++++--------- udp_internal.h | 10 ++- udp_vu.c | 194 +++++++++++++++++++++++++------------------------ vu_common.c | 82 +++++++++++++-------- vu_common.h | 20 +++-- 8 files changed, 282 insertions(+), 181 deletions(-) -- 2.53.0

2 25

[PATCH 0/6] Unify TCP and UDP forwarding tables
by David Gibson 11 Mar '26

11 Mar '26

This will make the dynamic update protocol and future forwarding extensions easier. Along the way I spotted a number of other minor faults, and have fixed those too. David Gibson (6): conf, fwd: Make overall forwarding mode local to conf path tcp: Remove stale description of port_to_tap field fwd: Don't initialise unused port bitmaps Fix misnamed field in struct ctx comments fwd: Split forwarding table from port scanning state fwd: Unify TCP and UDP forwarding tables conf.c | 129 ++++++++++++++++------------- flow.c | 23 ++---- fwd.c | 247 ++++++++++++++++++++++++++++++++++---------------------- fwd.h | 58 ++++++------- passt.c | 3 + passt.h | 7 +- tcp.c | 8 +- tcp.h | 11 +-- udp.c | 9 +-- udp.h | 8 +- 10 files changed, 282 insertions(+), 221 deletions(-) -- 2.53.0

2 9