qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: Planning for 0.13


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=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 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 Liguori
We'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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]