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

[Michael S. Tsirkin]

On Wed, Jan 06, 2010 at 09:10:30AM -0600, Anthony Liguori wrote:
> 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.

You listed them yourself. read/write versus send/recv,
vnet header.

>>> 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.

Then they need to support more than one qemu version,
it gets messy real fast.

>>> 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.

Not only for windows. With packet sockets you must use send/recv to
supply socket protocol. You must query tap to find out about UFO
support. There will be more.

>>>>> 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


How otherwise would scripts know how to talk to qemu?
Just just happens to match command line format you say?
And the way to discover what that format is ... how exactly?

Look, yes we could split this stuff out but this is just maintainance
headache, each change in backend will now need to be done in multiple
places, we'll have to care about old scripts, new scripts, it's just a
mess and at the end we will get existing functionality back and codebase
which is harder to debug and develop.

-- 
MST