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

[Anthony Liguori <aliguori@linux.vnet.ibm.com>]

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