On Wed, Jan 06, 2010 at 07:34:26AM -0600, Anthony Liguori wrote: > On 01/06/2010 07:20 AM, Michael S. Tsirkin wrote: >>> 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. > > It's the same mechanism, no? > > I want to move to a single net backend that would be something like -net > fd. Here are some possible invocations: > > -net fd,fd=3,type=tun,vnet=off > -net fd,helper="/usr/libexec/qemu-net-vepa --arg-if=eth0" > -net fd,fd=3,type=socket,vnet=off
We currently don't let users control whether vnet header is activated in tap and IMO we are better off this way, let qemu find out support itself. > -net fd,fd=3,type=vhost > > It's really a simple thing to do and it means that we can always > implement any backend outside of qemu. Look at existing backends, each of them has some quirks in qemu. It's not realistic to expect that future backends won't need any more. > As part of this, I would like: > > -net vepa,if=eth0 > > To automatically translate to: > > -net fd,helper="/usr/libexec/qemu-net-vepa --arg-if=eth0" > > I'm also open to the idea of using shared libraries if people really > think it's a good idea. What does all of this buy us? The helpers will still need to be shipped with qemu. >> 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. >> > > There really isn't much a protocol here. Helpers get handed a domain > socket, then connect and send an fd via SCM_RIGHTS. They pass a string > as part of that message that just happens to be equivalent to the arg > string that would normally be passed to -net fd. How do helpers know which arguments are legal? Also, e.g. with vhost-net you can open it in a helper script but you must do the rest of the set up in qemu. >> 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. >> > > The whole suid binary thing is someone orthogonal to my goal here. The > observation is that 99% of what people want in terms of network backends > really just boils down to, here's a file descriptor, interact with it in > one of a very small number of ways. Each new backend seems to have its own quirks. Nothing seems gained by moving handling them around. >>> 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. >> > > It's not about security, it's about not making qemu the gateway to > implementing arbitrarily complex network mechanisms. There's no reason > qemu should have to know anything about vepa, for instance. > > Regards, > > Anthony Liguori We'll still need to write all the scripts and bundle them with qemu. So ... I fail to see -- MST