On Wed, 13 May 2026 13:52:08 +0200
Laurent Vivier
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.
Sorry to bring (likely) bad news, but this series seems to introduce a regression: I got the migration/rampstream_in tests fail twice in a row, which I've never saw happening (I think I saw a single failure a long time ago when the machine had a high CPU load, but nothing else). I'm currently bisecting and the bisect seems to point towards the end of the series (probably 10/10), but I haven't finished yet. I'll keep you posted. I haven't spotted anything that might cause issues there. It's probably worth mentioning that after migration we send pretty small TCP frames (window probes), but I have no idea yet if that has anything to do. -- Stefano