April 2026 - dev

[PATCH v4 0/4] vhost-user,tcp: Handle multiple iovec entries per virtqueue element
by Laurent Vivier 01 Apr '26

01 Apr '26

This is the TCP counterpart to the UDP multi-iov series. It converts the TCP vhost-user receive path from direct pointer arithmetic (via vu_eth(), vu_ip(), etc.) to the iov_tail abstraction, removing the assumption that all headers reside in a single contiguous buffer. With this series applied, the TCP path correctly handles virtio-net drivers that provide multiple buffers per virtqueue element (e.g. iPXE provides the vnet header in the first buffer and the frame payload in a second one), matching the support already present in the UDP path. Based-on: 20260401192326.1783350-1-lvivier(a)redhat.com v4: - fix error during rebasei, s/vu_pad_len/vu_pad/ v3: - Rebased on top of [PATCH 00/10] vhost-user: Preparatory series for multiple iovec entries per virtqueue element v2: - add "tcp: Encode checksum computation flags in a single parameter" - remove IOV_PUT_HEADER()/with_header() and use IOV_PUSH_HEADER() - don't use the iov_tail to provide the headers to the functions Laurent Vivier (4): tcp: Encode checksum computation flags in a single parameter tcp_vu: Build headers on the stack and write them into the iovec tcp_vu: Support multibuffer frames in tcp_vu_sock_recv() tcp_vu: Support multibuffer frames in tcp_vu_send_flag() iov.c | 1 - tcp.c | 25 ++-- tcp_buf.c | 23 +-- tcp_internal.h | 7 +- tcp_vu.c | 395 +++++++++++++++++++++++++++++-------------------- vu_common.h | 20 --- 6 files changed, 265 insertions(+), 206 deletions(-) -- 2.53.0

1 4

[PATCH v3 0/4] vhost-user,tcp: Handle multiple iovec entries per virtqueue element
by Laurent Vivier 01 Apr '26

01 Apr '26

This is the TCP counterpart to the UDP multi-iov series. It converts the TCP vhost-user receive path from direct pointer arithmetic (via vu_eth(), vu_ip(), etc.) to the iov_tail abstraction, removing the assumption that all headers reside in a single contiguous buffer. With this series applied, the TCP path correctly handles virtio-net drivers that provide multiple buffers per virtqueue element (e.g. iPXE provides the vnet header in the first buffer and the frame payload in a second one), matching the support already present in the UDP path. Based-on: 20260401192326.1783350-1-lvivier(a)redhat.com v3: - Rebased on top of [PATCH 00/10] vhost-user: Preparatory series for multiple iovec entries per virtqueue element v2: - add "tcp: Encode checksum computation flags in a single parameter" - remove IOV_PUT_HEADER()/with_header() and use IOV_PUSH_HEADER() - don't use the iov_tail to provide the headers to the functions Laurent Vivier (4): tcp: Encode checksum computation flags in a single parameter tcp_vu: Build headers on the stack and write them into the iovec tcp_vu: Support multibuffer frames in tcp_vu_sock_recv() tcp_vu: Support multibuffer frames in tcp_vu_send_flag() iov.c | 1 - tcp.c | 25 ++-- tcp_buf.c | 23 +-- tcp_internal.h | 7 +- tcp_vu.c | 395 +++++++++++++++++++++++++++++-------------------- vu_common.h | 20 --- 6 files changed, 265 insertions(+), 206 deletions(-) -- 2.53.0

1 4

[PATCH v6 0/3] vhost-user,udp: Handle multiple iovec entries per virtqueue element
by Laurent Vivier 01 Apr '26

01 Apr '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. Based-on: 20260401191826.1782394-1-lvivier(a)redhat.com v6: - Rebased on top of [PATCH 00/10] vhost-user: Preparatory series for multiple iovec entries per virtqueue element v5: - This version doesn't change the padding system regarding v4, it's a complex task that will be addressed in another version - reorder patches and add new patches - remove IOV_PUT_HEADER()/with_header() and introduce IOV_PUSH_HEADER() - don't use the iov_tail to provide the headers to the functions - move vu_set_vnethdr() to vu_flush(), extract vu_queue_notify() - move vu_flush() inside loop in tcp_vu_data_from_sock() to flush data by frame and not by full data length v4: - rebase - replace ASSERT() by assert() 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 (3): udp_vu: Allow virtqueue elements with multiple iovec entries iov: Introduce IOV_PUSH_HEADER() macro udp: Pass iov_tail to udp_update_hdr4()/udp_update_hdr6() iov.c | 22 ++++++++++ iov.h | 11 +++++ udp.c | 70 +++++++++++++++++-------------- udp_internal.h | 4 +- udp_vu.c | 110 +++++++++++++++++++++++++------------------------ 5 files changed, 131 insertions(+), 86 deletions(-) -- 2.53.0

1 3

[PATCH 00/10] vhost-user: Preparatory series for multiple iovec entries per virtqueue element
by Laurent Vivier 01 Apr '26

01 Apr '26

Currently, the vhost-user path assumes each virtqueue element contains exactly one iovec entry covering the entire frame. This assumption breaks as 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. This series refactors the vhost-user data path so that frame lengths, header sizes, and padding are tracked and passed explicitly rather than being derived from iovec sizes. This decoupling is a prerequisite for correctly handling padding of multi-buffer frames. The changes in this series can be split in 3 groups: - New iov helpers (patches 1-2): iov_memset() and iov_memcopy() operate across iovec boundaries. These are needed by the final patch to pad and copy frame data when a frame spans multiple iovec entries. - Structural refactoring (patches 3-5): Move vnethdr setup into vu_flush(), separate virtqueue management from socket I/O in the UDP path, and pass iov arrays explicitly instead of using file-scoped state. These changes make it possible to pass explicit frame lengths through the stack, which is required to pad frames independently of iovec layout. - Explicit length passing throughout the stack (patches 6-10): Thread explicit L4, L2, frame, and data lengths through checksum, pcap, vu_flush(), and tcp_fill_headers(), replacing lengths that were previously derived from iovec sizes. With lengths tracked explicitly, the final patch can centralise Ethernet frame padding into vu_collect() and a new vu_pad() helper that correctly pads frames spanning multiple iovec entries. Laurent Vivier (10): iov: Introduce iov_memset() iov: Add iov_memcopy() to copy data between iovec arrays vu_common: Move vnethdr setup into vu_flush() udp_vu: Move virtqueue management from udp_vu_sock_recv() to its caller udp_vu: Pass iov explicitly to helpers instead of using file-scoped array checksum: Pass explicit L4 length to checksum functions pcap: Pass explicit L2 length to pcap_iov() vu_common: Pass explicit frame length to vu_flush() tcp: Pass explicit data length to tcp_fill_headers() vhost-user: Centralise Ethernet frame padding in vu_collect() and vu_pad() checksum.c | 35 ++++++----- checksum.h | 6 +- iov.c | 78 ++++++++++++++++++++++++ iov.h | 5 ++ pcap.c | 37 ++++++++--- pcap.h | 2 +- tap.c | 6 +- tcp.c | 14 +++-- tcp_buf.c | 3 +- tcp_internal.h | 2 +- tcp_vu.c | 62 +++++++++---------- udp.c | 5 +- udp_vu.c | 162 ++++++++++++++++++++++++++----------------------- vu_common.c | 58 ++++++++++-------- vu_common.h | 5 +- 15 files changed, 304 insertions(+), 176 deletions(-) -- 2.53.0

1 10

[PATCH v1 2/2] tap, tcp, udp: Use rate-limited logging
by Anshu Kumari 01 Apr '26

01 Apr '26

Now that rate-limited logging macros are available, promote several debug messages to higher severity levels. These messages were previously kept at debug to prevent guests from flooding host logs, but with rate limiting they can safely be made visible in normal operation. In tap.c, refactor tap4_is_fragment() to use warn_ratelimit() instead of its ad-hoc rate limiting, and promote the guest MAC address change message to info level. In tcp.c, promote the invalid TCP SYN endpoint message to warn level. In udp.c and udp_flow.c, promote flow allocation failures and dropped datagram messages to warn level, and rate-limit the unrecoverable socket error message. Link: https://bugs.passt.top/show_bug.cgi?id=134 Signed-off-by: Anshu Kumari <anskuma(a)redhat.com> --- - Inside udp.c - David: should this be changed to warn_ratelimit? I am not sure about it debug("%s error on UDP socket %i: %s", str_ee_origin(ee), s, strerror_(ee->ee_errno)); --- tap.c | 14 ++++---------- tcp.c | 2 +- udp.c | 6 +++--- udp_flow.c | 4 ++-- 4 files changed, 10 insertions(+), 16 deletions(-) diff --git a/tap.c b/tap.c index 1049e02..f569b61 100644 --- a/tap.c +++ b/tap.c @@ -686,17 +686,11 @@ static bool tap4_is_fragment(const struct iphdr *iph, const struct timespec *now) { if (ntohs(iph->frag_off) & ~IP_DF) { - /* Ratelimit messages */ - static time_t last_message; static unsigned num_dropped; num_dropped++; - if (now->tv_sec - last_message > FRAGMENT_MSG_RATE) { - warn("Can't process IPv4 fragments (%u dropped)", - num_dropped); - last_message = now->tv_sec; - num_dropped = 0; - } + warn_ratelimit(now, "Can't process IPv4 fragments (%u dropped)", + num_dropped); return true; } return false; @@ -1115,8 +1109,8 @@ void tap_add_packet(struct ctx *c, struct iov_tail *data, char bufmac[ETH_ADDRSTRLEN]; memcpy(c->guest_mac, eh->h_source, ETH_ALEN); - debug("New guest MAC address observed: %s", - eth_ntop(c->guest_mac, bufmac, sizeof(bufmac))); + info_ratelimit(now, "New guest MAC address observed: %s", + eth_ntop(c->guest_mac, bufmac, sizeof(bufmac))); proto_update_l2_buf(c->guest_mac); } diff --git a/tcp.c b/tcp.c index 8ea9be8..3d3b80d 100644 --- a/tcp.c +++ b/tcp.c @@ -1688,7 +1688,7 @@ static void tcp_conn_from_tap(const struct ctx *c, sa_family_t af, !inany_is_unicast(&ini->oaddr) || ini->oport == 0) { char sstr[INANY_ADDRSTRLEN], dstr[INANY_ADDRSTRLEN]; - debug("Invalid endpoint in TCP SYN: %s:%hu -> %s:%hu", + warn_ratelimit(now, "Invalid endpoint in TCP SYN: %s:%hu -> %s:%hu", inany_ntop(&ini->eaddr, sstr, sizeof(sstr)), ini->eport, inany_ntop(&ini->oaddr, dstr, sizeof(dstr)), ini->oport); goto cancel; diff --git a/udp.c b/udp.c index 1fc5a42..1ef5e7a 100644 --- a/udp.c +++ b/udp.c @@ -871,7 +871,7 @@ void udp_sock_fwd(const struct ctx *c, int s, int rule_hint, /* Clear errors & carry on */ if (udp_sock_errs(c, s, FLOW_SIDX_NONE, frompif, port) < 0) { - err( + err_ratelimit(now, "UDP: Unrecoverable error on listening socket: (%s port %hu)", pif_name(frompif), port); /* FIXME: what now? close/re-open socket? */ @@ -898,7 +898,7 @@ void udp_sock_fwd(const struct ctx *c, int s, int rule_hint, pif_name(frompif), pif_name(topif)); discard = true; } else { - debug("Discarding datagram without flow"); + warn_ratelimit(now, "Discarding datagram without flow"); discard = true; } @@ -1042,7 +1042,7 @@ int udp_tap_handler(const struct ctx *c, uint8_t pif, if (!(uflow = udp_at_sidx(tosidx))) { char sstr[INET6_ADDRSTRLEN], dstr[INET6_ADDRSTRLEN]; - debug("Dropping datagram with no flow %s %s:%hu -> %s:%hu", + warn_ratelimit(now, "Dropping datagram with no flow %s %s:%hu -> %s:%hu", pif_name(pif), inet_ntop(af, saddr, sstr, sizeof(sstr)), src, inet_ntop(af, daddr, dstr, sizeof(dstr)), dst); diff --git a/udp_flow.c b/udp_flow.c index 7e2453e..9343b4b 100644 --- a/udp_flow.c +++ b/udp_flow.c @@ -235,7 +235,7 @@ flow_sidx_t udp_flow_from_sock(const struct ctx *c, uint8_t pif, if (!(flow = flow_alloc())) { char sastr[SOCKADDR_STRLEN]; - debug("Couldn't allocate flow for UDP datagram from %s %s", + warn_ratelimit(now, "Couldn't allocate flow for UDP datagram from %s %s", pif_name(pif), sockaddr_ntop(s_in, sastr, sizeof(sastr))); return FLOW_SIDX_NONE; } @@ -292,7 +292,7 @@ flow_sidx_t udp_flow_from_tap(const struct ctx *c, if (!(flow = flow_alloc())) { char sstr[INET6_ADDRSTRLEN], dstr[INET6_ADDRSTRLEN]; - debug("Couldn't allocate flow for UDP datagram from %s %s:%hu -> %s:%hu", + warn_ratelimit(now, "Couldn't allocate flow for UDP datagram from %s %s:%hu -> %s:%hu", pif_name(pif), inet_ntop(af, saddr, sstr, sizeof(sstr)), srcport, inet_ntop(af, daddr, dstr, sizeof(dstr)), dstport); -- 2.53.0

1 0

[PATCH] SELinux: Dontaudit access to dri devices
by Johannes Segitz 01 Apr '26

01 Apr '26

Currently podman can pass a FD to a DRI device to pasta, leading to AVCs like this: avc: denied { read write } comm="pasta" path="/dev/dri/renderD128" scontext=unconfined_u:unconfined_r:pasta_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dri_device_t:s0 tclass=chr_file These are harmless, so dontaudit them Signed-off-by: Johannes Segitz <jsegitz(a)suse.de> --- contrib/selinux/pasta.te | 2 ++ 1 file changed, 2 insertions(+) diff --git a/contrib/selinux/pasta.te b/contrib/selinux/pasta.te index fb51416..4bc7dcc 100644 --- a/contrib/selinux/pasta.te +++ b/contrib/selinux/pasta.te @@ -262,3 +262,5 @@ if (pasta_bind_all_ports) { allow pasta_t port_type:tcp_socket { accept getopt name_bind name_connect }; allow pasta_t port_type:udp_socket { accept getopt name_bind }; } + +dev_dontaudit_rw_dri(pasta_t) -- 2.53.0

2 4