- dev - passt

[PATCH 0/3] Fix migration bugs
by David Gibson 19 Mar '25

19 Mar '25

This series addresses the migration bug I encountered with different (simulated) source and target hosts. While fixing it, I spotted another problem in the migration stream format, with the marshalling of the MSS parameter, so I fixed that as well. Because this represents a change in the migration stream format, but we don't actually bump the version until 3/3, this series should be applied "atomically" - all 3 patches, or none of them. David Gibson (3): migrate, tcp: More careful marshalling of mss parameter during migration migrate, tcp: Migrate RFC7323 timestamp migrate: Bump migration version number migrate.c | 10 ++++++--- tcp.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++- tcp_conn.h | 2 ++ 3 files changed, 74 insertions(+), 4 deletions(-) -- 2.48.1

2 4

[PATCH 0/2] udp: add guest-to-remote traceroute for IPv4
by Jon Maloy 19 Mar '25

19 Mar '25

We add support for UDP/IPv4 traceroute in the tap-sock direction. More will follow when this one is settled. Jon Maloy (2): udp: correct source address for ICMP messages udp: support traceroute for IPv4 packet.h | 2 ++ tap.c | 8 ++++++-- udp.c | 36 ++++++++++++++++++++++++------------ udp.h | 3 ++- 4 files changed, 34 insertions(+), 15 deletions(-) -- 2.48.1

2 6

Migration failure across bridge
by David Gibson 19 Mar '25

19 Mar '25

Continued investigating the problem with migration failing across a bridge. Good news is I've found the problem... or at least one problem. Bad news is we'll have to change the migration stream format to fix it. The packets are being dropped in tcp_validate_incoming() due to a failed PAWS check (skb drop reason "TCP_RFC7323_PAWS"). That in turn looks to be because we don't preserve TCP timestamp state across the migration. We preserve _whether_ TCP timestamps are active on the connection (TCPOPT_TIMESTAMP entry in TCP_REPAIR_OPTIONS), but we don't preserve the current timestamp values (TCP_TIMESTAMP socket option). The equivalent CRIU code is https://github.com/checkpoint-restore/criu/blob/d18912fc88f3dc7bde5fdfa3575… and https://github.com/checkpoint-restore/criu/blob/d18912fc88f3dc7bde5fdfa3575… I'll work on writing a fix tomorrow. Not yet sure why we didn't hit this with a local migration. I'm guessing some part of being a local connection means we're bypassing the PAWS check. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson

2 2

[PATCH] passt-repair: Fix build with -Werror=format-security
by Stefano Brivio 19 Mar '25

19 Mar '25

Fixes: 04701702471e ("passt-repair: Add directory watch") Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com> --- Note: I just pushed this for my own sanity, as it's trivial and builds are otherwise broken on CentOS Stream / RHEL. I'm posting for review anyway in the unlikely case something can ever be wrong with this. passt-repair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/passt-repair.c b/passt-repair.c index 8bb3f00..120f7aa 100644 --- a/passt-repair.c +++ b/passt-repair.c @@ -150,7 +150,7 @@ int main(int argc, char **argv) _exit(1); } - ret = snprintf(a.sun_path, sizeof(a.sun_path), path); + ret = snprintf(a.sun_path, sizeof(a.sun_path), "%s", path); inotify_dir = true; } else { ret = snprintf(a.sun_path, sizeof(a.sun_path), "%s", argv[1]); -- 2.43.0

2 1

[PATCH v2] conf: Unify several paths in conf_ports()
by David Gibson 18 Mar '25

18 Mar '25

In conf_ports() we have three different paths which actually do the setup of an individual forwarded port: one for the "all" case, one for the exclusions only case and one for the range of ports with possible exclusions case. We can unify those cases using a new helper which handles a single range of ports, with a bitmap of exclusions. Although this is slightly longer (largely due to the new helpers function comment), it reduces duplicated logic. It will also make future improvements to the tracking of port forwards easier. The new conf_ports_range_except() function has a pretty prodigious parameter list, but I still think it's an overall improvement in conceptual complexity. Signed-off-by: David Gibson <david(a)gibson.dropbear.id.au> --- conf.c | 173 ++++++++++++++++++++++++++++++--------------------------- 1 file changed, 90 insertions(+), 83 deletions(-) v2: * Commit message updated slightly, but otherwise unmodified. diff --git a/conf.c b/conf.c index 065e7201..4e0099ba 100644 --- a/conf.c +++ b/conf.c @@ -123,6 +123,75 @@ static int parse_port_range(const char *s, char **endptr, return 0; } +/** + * conf_ports_range_except() - Set up forwarding for a range of ports minus a + * bitmap of exclusions + * @c: Execution context + * @optname: Short option name, t, T, u, or U + * @optarg: Option argument (port specification) + * @fwd: Pointer to @fwd_ports to be updated + * @addr: Listening address + * @ifname: Listening interface + * @first: First port to forward + * @last: Last port to forward + * @exclude: Bitmap of ports to exclude + * @to: Port to translate @first to when forwarding + * @weak: Ignore errors, as long as at least one port is mapped + */ +static void conf_ports_range_except(const struct ctx *c, char optname, + const char *optarg, struct fwd_ports *fwd, + const union inany_addr *addr, + const char *ifname, + uint16_t first, uint16_t last, + const uint8_t *exclude, uint16_t to, + bool weak) +{ + bool bound_one = false; + unsigned i; + int ret; + + if (first == 0) { + die("Can't forward port 0 for option '-%c %s'", + optname, optarg); + } + + for (i = first; i <= last; i++) { + if (bitmap_isset(exclude, i)) + continue; + + if (bitmap_isset(fwd->map, i)) { + warn( +"Altering mapping of already mapped port number: %s", optarg); + } + + bitmap_set(fwd->map, i); + fwd->delta[i] = to - first; + + if (optname == 't') + ret = tcp_sock_init(c, addr, ifname, i); + else if (optname == 'u') + ret = udp_sock_init(c, 0, addr, ifname, i); + else + /* No way to check in advance for -T and -U */ + ret = 0; + + if (ret == -ENFILE || ret == -EMFILE) { + die("Can't open enough sockets for port specifier: %s", + optarg); + } + + if (!ret) { + bound_one = true; + } else if (!weak) { + die("Failed to bind port %u (%s) for option '-%c %s'", + i, strerror_(-ret), optname, optarg); + } + } + + if (!bound_one) + die("Failed to bind any port for '-%c %s'", optname, optarg); +} + /** * conf_ports() - Parse port configuration options, initialise UDP/TCP sockets * @c: Execution context @@ -135,10 +204,9 @@ static void conf_ports(const struct ctx *c, char optname, const char *optarg, { union inany_addr addr_buf = inany_any6, *addr = &addr_buf; char buf[BUFSIZ], *spec, *ifname = NULL, *p; - bool exclude_only = true, bound_one = false; uint8_t exclude[PORT_BITMAP_SIZE] = { 0 }; + bool exclude_only = true; unsigned i; - int ret; if (!strcmp(optarg, "none")) { if (fwd->mode) @@ -173,32 +241,15 @@ static void conf_ports(const struct ctx *c, char optname, const char *optarg, fwd->mode = FWD_ALL; - /* Skip port 0. It has special meaning for many socket APIs, so - * trying to bind it is not really safe. - */ - for (i = 1; i < NUM_PORTS; i++) { + /* Exclude ephemeral ports */ + for (i = 0; i < NUM_PORTS; i++) if (fwd_port_is_ephemeral(i)) - continue; - - bitmap_set(fwd->map, i); - if (optname == 't') { - ret = tcp_sock_init(c, NULL, NULL, i); - if (ret == -ENFILE || ret == -EMFILE) - goto enfile; - if (!ret) - bound_one = true; - } else if (optname == 'u') { - ret = udp_sock_init(c, 0, NULL, NULL, i); - if (ret == -ENFILE || ret == -EMFILE) - goto enfile; - if (!ret) - bound_one = true; - } - } - - if (!bound_one) - goto bind_all_fail; + bitmap_set(exclude, i); + conf_ports_range_except(c, optname, optarg, fwd, + NULL, NULL, + 1, NUM_PORTS - 1, exclude, + 1, true); return; } @@ -275,37 +326,15 @@ static void conf_ports(const struct ctx *c, char optname, const char *optarg, } while ((p = next_chunk(p, ','))); if (exclude_only) { - /* Skip port 0. It has special meaning for many socket APIs, so - * trying to bind it is not really safe. - */ - for (i = 1; i < NUM_PORTS; i++) { - if (fwd_port_is_ephemeral(i) || - bitmap_isset(exclude, i)) - continue; - - bitmap_set(fwd->map, i); - - if (optname == 't') { - ret = tcp_sock_init(c, addr, ifname, i); - if (ret == -ENFILE || ret == -EMFILE) - goto enfile; - if (!ret) - bound_one = true; - } else if (optname == 'u') { - ret = udp_sock_init(c, 0, addr, ifname, i); - if (ret == -ENFILE || ret == -EMFILE) - goto enfile; - if (!ret) - bound_one = true; - } else { - /* No way to check in advance for -T and -U */ - bound_one = true; - } - } - - if (!bound_one) - goto bind_all_fail; + /* Exclude ephemeral ports */ + for (i = 0; i < NUM_PORTS; i++) + if (fwd_port_is_ephemeral(i)) + bitmap_set(exclude, i); + conf_ports_range_except(c, optname, optarg, fwd, + addr, ifname, + 1, NUM_PORTS - 1, exclude, + 1, true); return; } @@ -334,40 +363,18 @@ static void conf_ports(const struct ctx *c, char optname, const char *optarg, if ((*p != '\0') && (*p != ',')) /* Garbage after the ranges */ goto bad; - for (i = orig_range.first; i <= orig_range.last; i++) { - if (bitmap_isset(fwd->map, i)) - warn( -"Altering mapping of already mapped port number: %s", optarg); - - if (bitmap_isset(exclude, i)) - continue; - - bitmap_set(fwd->map, i); - - fwd->delta[i] = mapped_range.first - orig_range.first; - - ret = 0; - if (optname == 't') - ret = tcp_sock_init(c, addr, ifname, i); - else if (optname == 'u') - ret = udp_sock_init(c, 0, addr, ifname, i); - if (ret) - goto bind_fail; - } + conf_ports_range_except(c, optname, optarg, fwd, + addr, ifname, + orig_range.first, orig_range.last, + exclude, + mapped_range.first, false); } while ((p = next_chunk(p, ','))); return; -enfile: - die("Can't open enough sockets for port specifier: %s", optarg); bad: die("Invalid port specifier %s", optarg); mode_conflict: die("Port forwarding mode '%s' conflicts with previous mode", optarg); -bind_fail: - die("Failed to bind port %u (%s) for option '-%c %s', exiting", - i, strerror_(-ret), optname, optarg); -bind_all_fail: - die("Failed to bind any port for '-%c %s', exiting", optname, optarg); } /** -- 2.48.1

3 6

Testing vhost-user with "virtio-net: tweak for better TX performance in NAPI mode"
by Laurent Vivier 18 Mar '25

18 Mar '25

Hi, as reported by Stefano there is an asymmetry in the throughput between host and guest with vhost-user. I've tested the following kernel patch from Jason to see if it can improve the performance: ------------------------------------------------------------------------------ commit e13b6da7045f997e1a5a5efd61d40e63c4fc20e8 Author: Jason Wang <jasowang(a)redhat.com> Date: Tue Feb 18 10:39:08 2025 +0800 virtio-net: tweak for better TX performance in NAPI mode There are several issues existed in start_xmit(): - Transmitted packets need to be freed before sending a packet, this introduces delay and increases the average packets transmit time. This also increase the time that spent in holding the TX lock. - Notification is enabled after free_old_xmit_skbs() which will introduce unnecessary interrupts if TX notification happens on the same CPU that is doing the transmission now (actually, virtio-net driver are optimized for this case). So this patch tries to avoid those issues by not cleaning transmitted packets in start_xmit() when TX NAPI is enabled and disable notifications even more aggressively. Notification will be since the beginning of the start_xmit(). But we can't enable delayed notification after TX is stopped as we will lose the notifications. Instead, the delayed notification needs is enabled after the virtqueue is kicked for best performance. Performance numbers: 1) single queue 2 vcpus guest with pktgen_sample03_burst_single_flow.sh (burst 256) + testpmd (rxonly) on the host: - When pinning TX IRQ to pktgen VCPU: split virtqueue PPS were increased 55% from 6.89 Mpps to 10.7 Mpps and 32% TX interrupts were eliminated. Packed virtqueue PPS were increased 50% from 7.09 Mpps to 10.7 Mpps, 99% TX interrupts were eliminated. - When pinning TX IRQ to VCPU other than pktgen: split virtqueue PPS were increased 96% from 5.29 Mpps to 10.4 Mpps and 45% TX interrupts were eliminated; Packed virtqueue PPS were increased 78% from 6.12 Mpps to 10.9 Mpps and 99% TX interrupts were eliminated. 2) single queue 1 vcpu guest + vhost-net/TAP on the host: single session netperf from guest to host shows 82% improvement from 31Gb/s to 58Gb/s, %stddev were reduced from 34.5% to 1.9% and 88% of TX interrupts were eliminated. Signed-off-by: Jason Wang <jasowang(a)redhat.com> Acked-by: Michael S. Tsirkin <mst(a)redhat.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> ------------------------------------------------------------------------------ systemctl stop firewalld.service || service iptables stop || iptables -Ft /sbin/sysctl -w net.core.rmem_max=536870912 /sbin/sysctl -w net.core.wmem_max=536870912 ____ I made my test using 6.14-rc7 kernel: From guest: iperf3 -c 10.6.68.254 -P2 -Z -t5 -l 1M -w 16M [SUM] 0.00-5.00 sec 14.5 GBytes 24.9 Gbits/sec 0 sender [SUM] 0.00-5.00 sec 14.5 GBytes 24.9 Gbits/sec receiver From host: iperf3 -c localhost -P2 -Z -t5 -p 10001 -l 1M -w 16M [SUM] 0.00-5.00 sec 28.9 GBytes 49.6 Gbits/sec 0 sender [SUM] 0.00-5.03 sec 28.8 GBytes 49.2 Gbits/sec receiver ____ The results with a 6.14-rc7 + e13b6da7045f: From guest: iperf3 -c 10.6.68.254 -P2 -Z -t5 -l 1M -w 16M [SUM] 0.00-5.00 sec 14.8 GBytes 25.4 Gbits/sec 0 sender [SUM] 0.00-5.01 sec 14.8 GBytes 25.4 Gbits/sec receiver From host: iperf3 -c localhost -P2 -Z -t5 -p 10001 -l 1M -w 16M [SUM] 0.00-5.00 sec 28.5 GBytes 48.9 Gbits/sec 0 sender [SUM] 0.00-5.03 sec 28.4 GBytes 48.6 Gbits/sec receiver We have only a 2% improvement. Thanks, Laurent

2 1

Migration testing with different host IPs
by David Gibson 16 Mar '25

16 Mar '25

I finally managed to set up tests simulating migration where the source and target host are different machines which may have different IPs. I'm getting some weird failures, but first the setup itself, since it might be useful. I'm attaching nsqemu.sh, which is based on my earlier qemu.sh. # Steps to run 1. In terminal 1, run $ nsqemu.sh box 2. In terminal 2, run $ nsqemu.sh source 3. In terminal 3, run $ nsqemu.sh target 4. In terminal 2 set up guest network # ip link set eth0 up # dhclient eth0 5. In terminal 2 (source) connect to the server running terminal 1 # socat STDIO TCP4:172.16.1.1:5555 6. Send some data back and forth between terminal 2 (source guest) and terminal 1 (external peer) 7. Initiate the migration in terminal 2 C-a c (qemu) migrate tcp:172.16.55.22:4444 8. Wait for migration to complete, watching terminal 3 (target guest) 9. Attempt to send data back and forth between terminal 3 (target guest) and terminal 1 (external peer) This isn't quite working for me, for reasons I haven't figured out yet # Testing with different source and target host IPs To test this change the IP= lines in the source and target sections so that they're different. This test is mostly working for me; the target drops the connection without breaking continuing connectivity on the target. # Network model The "box" creates an L1 namespace to host everything. It contains a bridge device "br0" with address 172.16.1.1. It's not connected to the outside internet. The peer server runs here. The source and target "hosts" are L2 namespaces, each with a veth attached to br0, and *both* with address 172.16.1.111, default route via 172.16.1.1 Additionally there's a veth directly between the two L2 spaces, used for the actual migration stream. It has addresses 172.16.55.11 and 172.16.55.22. # Weird failure For some reason, after the migration with this setup the target guest receives further incoming data from the peer server, but further outbound data seems to reach the bridge.. but not the server process. br.pcap attached. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson

2 2

[PATCH v2 1/4] test focus
by David Gibson 15 Mar '25

15 Mar '25

--- test/run | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/test/run b/test/run index 4e86f30f..5278b48c 100755 --- a/test/run +++ b/test/run @@ -81,9 +81,9 @@ run() { test passt/shutdown teardown pasta - setup pasta_options - test pasta_options/log_to_file - teardown pasta_options + #setup pasta_options + #test pasta_options/log_to_file + #teardown pasta_options setup build test pasta_podman/bats @@ -169,24 +169,24 @@ run() { VALGRIND=0 VHOST_USER=0 - setup passt_in_ns - test passt/ndp - test passt_in_ns/dhcp - test perf/passt_tcp - test perf/passt_udp - test perf/pasta_tcp - test perf/pasta_udp - test passt_in_ns/shutdown - teardown passt_in_ns + #setup passt_in_ns + #test passt/ndp + #test passt_in_ns/dhcp + #test perf/passt_tcp + #test perf/passt_udp + #test perf/pasta_tcp + #test perf/pasta_udp + #test passt_in_ns/shutdown + #teardown passt_in_ns VHOST_USER=1 - setup passt_in_ns - test passt_vu/ndp - test passt_vu_in_ns/dhcp - test perf/passt_vu_tcp - test perf/passt_vu_udp - test passt_vu_in_ns/shutdown - teardown passt_in_ns + #setup passt_in_ns + #test passt_vu/ndp + #test passt_vu_in_ns/dhcp + #test perf/passt_vu_tcp + #test perf/passt_vu_udp + #test passt_vu_in_ns/shutdown + #teardown passt_in_ns # TODO: Make those faster by at least pre-installing gcc and make on # non-x86 images, then re-enable. -- 2.48.1

2 5

[PATCH 0/4] Improve robustness of calculations related to frame size limits
by David Gibson 13 Mar '25

13 Mar '25

There are a number of places where we make calculations and checks around how large frames can be and where they sit in memory. Several of these are roughly correct, but can be wrong in certain edge cases. Improve robustness by clarifying what we're doing and being more careful about the edge cases. David Gibson (4): vu_common: Tighten vu_packet_check_range() packet: More cautious checks to avoid pointer arithmetic UB tap: Make size of pool_tap[46] purely a tuning parameter tap: Clarify calculation of TAP_MSGS packet.c | 25 +++++++++++++++++++++---- packet.h | 3 +++ passt.h | 2 -- tap.c | 43 ++++++++++++++++++++++++++++++++++++------- tap.h | 3 ++- vu_common.c | 15 ++++++++++----- 6 files changed, 72 insertions(+), 19 deletions(-) -- 2.48.1

1 4

[PATCH v2] flow, repair: Wait for a short while for passt-repair to connect
by Stefano Brivio 13 Mar '25

13 Mar '25

...and time out after that. This will be needed because of an upcoming change to passt-repair enabling it to start before passt is started, on both source and target, by means of an inotify watch. Once the inotify watch triggers, passt-repair will connect right away, but we have no guarantees that the connection completes before we start the migration process, so wait for it (for a reasonable amount of time). Signed-off-by: Stefano Brivio <sbrivio(a)redhat.com> --- v2: - Use 10 ms as timeout instead of 100 ms. Given that I'm unable to migrate a simple guest with 256 MiB of memory and no storage other than an initramfs in less than 4 milliseconds, at least on my test system (rather fast CPU threads and memory interface), I think that 10 ms shouldn't make a big difference in case passt-repair is not available for whatever reason - Move the static assert next to the initialisation of 'tv' flow.c | 20 ++++++++++++++++++++ repair.c | 31 +++++++++++++++++++++++++++++++ repair.h | 1 + 3 files changed, 52 insertions(+) diff --git a/flow.c b/flow.c index 749c498..5e64b79 100644 --- a/flow.c +++ b/flow.c @@ -911,6 +911,21 @@ static int flow_migrate_source_rollback(struct ctx *c, unsigned bound, int ret) return ret; } +/** + * flow_migrate_need_repair() - Do we need to set repair mode for any flow? + * + * Return: true if repair mode is needed, false otherwise + */ +static bool flow_migrate_need_repair(void) +{ + union flow *flow; + + foreach_established_tcp_flow(flow) + return true; + + return false; +} + /** * flow_migrate_repair_all() - Turn repair mode on or off for all flows * @c: Execution context @@ -966,6 +981,9 @@ int flow_migrate_source_pre(struct ctx *c, const struct migrate_stage *stage, (void)stage; (void)fd; + if (flow_migrate_need_repair()) + repair_wait(c); + if ((rc = flow_migrate_repair_all(c, true))) return -rc; @@ -1083,6 +1101,8 @@ int flow_migrate_target(struct ctx *c, const struct migrate_stage *stage, if (!count) return 0; + repair_wait(c); + if ((rc = flow_migrate_repair_all(c, true))) return -rc; diff --git a/repair.c b/repair.c index 3ee089f..ebeb248 100644 --- a/repair.c +++ b/repair.c @@ -27,6 +27,10 @@ #define SCM_MAX_FD 253 /* From Linux kernel (include/net/scm.h), not in UAPI */ +/* Wait for a while for TCP_REPAIR helper to connect if it's not there yet */ +#define REPAIR_ACCEPT_TIMEOUT_MS 10 +#define REPAIR_ACCEPT_TIMEOUT_US (REPAIR_ACCEPT_TIMEOUT_MS * 1000) + /* Pending file descriptors for next repair_flush() call, or command change */ static int repair_fds[SCM_MAX_FD]; @@ -138,6 +142,33 @@ void repair_handler(struct ctx *c, uint32_t events) repair_close(c); } +/** + * repair_wait() - Wait (with timeout) for TCP_REPAIR helper to connect + * @c: Execution context + */ +void repair_wait(struct ctx *c) +{ + struct timeval tv = { .tv_sec = 0, + .tv_usec = (long)(REPAIR_ACCEPT_TIMEOUT_US) }; + static_assert(REPAIR_ACCEPT_TIMEOUT_US < 1000 * 1000); + + if (c->fd_repair >= 0 || c->fd_repair_listen == -1) + return; + + if (setsockopt(c->fd_repair_listen, SOL_SOCKET, SO_RCVTIMEO, + &tv, sizeof(tv))) { + err_perror("Set timeout on TCP_REPAIR listening socket"); + return; + } + + repair_listen_handler(c, EPOLLIN); + + tv.tv_usec = 0; + if (setsockopt(c->fd_repair_listen, SOL_SOCKET, SO_RCVTIMEO, + &tv, sizeof(tv))) + err_perror("Clear timeout on TCP_REPAIR listening socket"); +} + /** * repair_flush() - Flush current set of sockets to helper, with current command * @c: Execution context diff --git a/repair.h b/repair.h index de279d6..1d37922 100644 --- a/repair.h +++ b/repair.h @@ -10,6 +10,7 @@ void repair_sock_init(const struct ctx *c); void repair_listen_handler(struct ctx *c, uint32_t events); void repair_handler(struct ctx *c, uint32_t events); void repair_close(struct ctx *c); +void repair_wait(struct ctx *c); int repair_flush(struct ctx *c); int repair_set(struct ctx *c, int s, int cmd); -- 2.43.0

2 5