On Mon Aug 10, 2026 at 4:11 AM EEST, David Gibson wrote:
Add the fd_vhost field on the context which will carry the file descriptor of the device and will indicate that the setup was successful. The vq field contains the kick, call and err file descriptors for both queues.
Also add vhost (mark if vhost acceleration was requested) and virtio_features field.
A couple of concerns about the command line interface. IIUC, once this is all ready the difference between vhost-kernel and regular tuntap should be neither guest-visible nor user-visible. So, assuming it does perform better, we'll probably want to make it the default.
So, making this explicitly an opt-in probably isn't what we want. Maybe --vhost on|off|auto would be a better idea, defaulting to off now, but auto (use if available) in future. "on" would be if the user definitely wants vhost, and would rather we exit than fall back if it's not available.
The auto option seems like a nice suggestion. will incorporate it in the next revision
A more minor concern is that there's the potential confusion between this and --vhost-user. Not immediately sure what we can do about this, since that's just reflecting the confusingly similar names of the underlying features.
Good point, will try to find a better fitting name
@@ -258,11 +263,14 @@ struct ctx { int fd_control; int fd_repair_listen; int fd_repair; + + int fd_vhost; unsigned char our_tap_mac[ETH_ALEN]; unsigned char guest_mac[ETH_ALEN]; uint16_t mtu;
uint64_t hash_secret[2]; + uint64_t virtio_features;
int ifi4; struct ip4_ctx ip4; @@ -288,6 +296,12 @@ struct ctx { struct udp_ctx udp; int no_icmp;
+ struct { + int kick_fd; + int call_fd; + int err_fd; + } vq[2]; + int no_dns; int no_dns_search; int no_dhcp_dns; @@ -300,6 +314,7 @@ struct ctx { int splice_only; int host_lo_to_ns_lo; int freebind; + int vhost; bool chroot_fallback;
int low_wmem;
It might be a bit neater to put the new vhost-kernel related fields into a substructure, rather than spreading them across struct ctx. At some point it would be nice to make the various tap backends a bit more pluggable / independent from each other. Doing that's obviously not in scope for this series, but keeping it's internal data all together will at least not make that job harder in the future.
Good suggestion. Will make things more organized for sure
-- 2.34.1