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: Michael S. Tsirkin
Subject: Re: [Qemu-devel] Re: Planning for 0.13
Date: Wed, 6 Jan 2010 15:20:45 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

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




reply via email to

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