[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Re: Planning for 0.13
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] Re: Planning for 0.13 |
Date: |
Wed, 6 Jan 2010 15:55:27 +0200 |
User-agent: |
Mutt/1.5.19 (2009-01-05) |
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
- [Qemu-devel] Planning for 0.13, Anthony Liguori, 2010/01/05
- [Qemu-devel] Re: Planning for 0.13, Anthony Liguori, 2010/01/05
- Re: [Qemu-devel] Planning for 0.13, Stefan Weil, 2010/01/05
- [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/05
- Re: [Qemu-devel] Re: Planning for 0.13, Anthony Liguori, 2010/01/05
- Re: [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Anthony Liguori, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Anthony Liguori, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13,
Michael S. Tsirkin <=
- Re: [Qemu-devel] Re: Planning for 0.13, Anthony Liguori, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Anthony Liguori, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Jamie Lokier, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Jamie Lokier, 2010/01/06
- Re: [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/06
- [Qemu-devel] Re: Planning for 0.13, Paolo Bonzini, 2010/01/06
- [Qemu-devel] Re: Planning for 0.13, Michael S. Tsirkin, 2010/01/06