Re: [Qemu-devel] QMP forward compatibility support

[Anthony Liguori <anthony@codemonkey.ws>]

On 01/11/2010 06:04 PM, Luiz Capitulino wrote:
>
>   As async messages were one of the reasons for having QMP, I thought
> that there was a consensus that making it part of the "original"
> protocol was ok, meaning that they would be always available.
>
>   That's the only reason.
>    

Right, but then it's not a capability, it's a core feature.  I just 
think it would be odd to advertise something as a capability and have it 
not behave like other ones.

>>> 3. We should add command(s) to enable/disable protocol features
>>>
>>> 4. Proper feature negotiation is done in pause mode. That's, clients
>>> interested in enabling new protocol features should start QEMU in
>>> pause mode and enable the features they are interested in using
>>>
>>>        
>> Why does this matter?
>>
>> We should be careful to support connecting to a VM long after it's been
>> started so any requirement like this is likely to cause trouble.
>>      
>   If I understood Markus's concerns correctly, he thinks that feature
> negotiation should happen before the protocol is "running", ie. make
> it part of the initial handshake.
>    

I think forcing the negotiation before executing any commands is a good 
idea.  But I don't think requiring the guest not to be running is 
necessary or even useful.

You don't want to have to support disabling and enabling features in the 
middle of a protocol session because then you have to deal with weird 
semantics.

>   Now, if everything is disabled by default and qemu might be running
> already, do we really need to have a handshake?
>    

I think it's valuable to have a discrete period of time when no commands 
have been executed where features can be enabled.  It simplifies some 
nasty edge conditions regarding enabling features while there are 
outstanding commands in flight.

Regards,

Anthony Liguori