kvm (and lguest!) want to get more speed out of the tun device. We already have an ABI for guest<->host comms, called virtio_ring; extending tun to understand this (with its async nature and batching) make for an efficient network.
But moreover: the same things that make virtio a good guest<->host transport make it appealing as a userspace<->kernel transport. So rather than do something just for tun, we create a /dev/vring. We could do a system call, but /dev/vring is sufficient. It is a nice, simple format for normal tun usage too. We do need a small (backwards-compatible) extension to the ring format if we're going to do this however, since we didn't previously expose the consumer's view of the producer (and vice verse) in the ring because the other end doesn't need to see it. However, it means that a middleman (as the kvm or lguest launcher process now becomes) cannot save and restore all the ring state. Cheers, Rusty. _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/virtualization
