|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Re: Planning for 0.13 |
Date: | Wed, 06 Jan 2010 09:10:30 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0 |
On 01/06/2010 07:55 AM, Michael S. Tsirkin wrote:
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=offWe 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 tap,vnet_hdr=off
-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.
Quirks in the send/receive paths? Can you be specific because I don't really think there are.
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.
Why? They can be separate packages that are maintained on their own and at their own pace.
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?
There is a set number of arguments that we support in qemu.. I think this is the sort of thing that is easier to discuss with code in hand.
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.
AFAICT, we have a hand full of types of fds. We have ones that require read/write, ones that require send/recv, and ones that require vhost interaction. Really, the first two are the same but the distinction is necessary for Windows.
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 LiguoriWe'll still need to write all the scripts and bundle them with qemu. So ... I fail to see
Again, I don't see why it needs to be bundled with qemu. Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |