On Wednesday 14 April 2010, Michael S. Tsirkin wrote: > > > > > > qemu needs the ability to inject raw packets into device > > > from userspace, bypassing vhost/virtio (for live migration). > > > > Ok, but since there is only a write callback and no read, it won't > > actually be able to do this with the current code, right? > > I think it'll work as is, with vhost qemu only ever writes, > never reads from device. We'll also never need GSO etc > which is a large part of what tap does (and macvtap will > have to do). Ah, I see. I didn't realize that qemu needs to write to the device even if vhost is used. But for the case of migration to another machine without vhost, wouldn't qemu also need to read? > > Moreover, it seems weird to have a new type of interface here that > > duplicates tap/macvtap with less functionality. Coming back > > to your original comment, this means that while mpassthru is currently > > not duplicating the actual code from macvtap, it would need to do > > exactly that to get the qemu interface right! > > > I don't think so, see above. anyway, both can reuse tun.c :) There is one significant difference between macvtap/mpassthru and tun/tap in that the directions are reversed. While macvtap and mpassthru forward data from write into dev_queue_xmit and from skb_receive into read, tun/tap forwards data from write into skb_receive and from start_xmit into read. Also, I'm not really objecting to duplicating code between macvtap and mpassthru, as the implementation can always be merged. My main objection is instead to having two different _user_interfaces_ for doing the same thing. Arnd -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
