On Wed, Jan 06, 2010 at 06:36:26AM -0600, Anthony Liguori wrote: > On 01/06/2010 04:49 AM, Michael S. Tsirkin wrote: >>> What's the remaining problem? >>> >> IIRC, proper memory/IO access filtering (get rid of map functions) and >> PCI Express. >> >> >>>> vepa networking >>>> >>>> >>> To me, this is covered with helpers. I really want to get qemu out of >>> the network setup business specifically because of things like vepa, >>> vmtag, and all of the other weird things that can be done. >>> >> I don't think you can now make vepa work this way. For existing >> kernels, they only way I see is using packet sockets, and that code >> already mostly works. One day, when macvtap is ready - who knows. But >> waiting for that would mean we won't have it in 0.13. >> > > We can use helpers for more than just tun/tap. My current thinking for > helpers is that they would give qemu an fd and then tell qemu how to > work with it. Basically, use read/write vs. send/recv, whether to use a > virtio-net header or not, etc.
Frankly I think this is too ambitious for 0.13, and I would like to avoid typing features that users need today to this effort. Note that management still needs ability to hand fd to qemu, so we can not require use of helpers for everyone. If the helpers are part of qemu itself, we do not gain anything from them besides (limited) security. But if not, we also get a protocol qemu<->helpers to maintain. Ugh. What I think is reasonable for 0.13, is what you posted: just allow helper script as an alternative way to get device fd, and have qemu do all the querying and feature negotiation exactly the way it already does. No protocol to maintain, command line users get some extra security, management is not affected at all. The only risk is that a new suid binary is installed. > That would allow a helper to open a raw socket, configure macvlan, and > then hand the fd over to qemu and tell qemu how to use it. Note binding to macvlan in a script buys you zero extra security as compared to opening socket and binding in qemu. > Regards, > > Anthony Liguori -- MST