Re: [Qemu-devel] Re: [PATCH] Split machine creation from the main loop

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/27/2011 05:33 AM, Avi Kivity wrote:
> On 02/24/2011 07:25 PM, Anthony Liguori wrote:
>>> Is it really necessary?  What's blocking us from initializing 
>>> chardevs early?
>>
>>
>> Well....
>>
>> We initialize all chardevs at once right now and what set of chardevs 
>> there are depends on the machine (by the way defaults are applied).  
>> You could initialize chardevs in two stages although that requires 
>> quite a bit of additional complexity.
>
> We could initialize chardevs on demand - that should resolve any 
> dependencies?

I think that potentially screws up the way -global works.  There's some 
deep black magic involved in how -global, defaults, and device 
initialization interact.

>>>
>>> It would be a pity to divorce the monitor from chardevs, they're 
>>> really flexible.
>>
>> Couple considerations:
>>
>> 1) chardevs don't support multiple simultaneous connections.  I view 
>> this as a blocker for QMP.
>
> What do you mean by that?   Something like ,server which keeps on 
> listening after it a connection is established?

,server won't allow multiple simultaneous connections.  CharDriverStates 
simply don't have a connection semantic.  There can only be one thing 
connected to it at a time.  This is why we don't use CharDriverState for 
VNC.

We should have another abstraction for connection based backend.  I'll 
take a go at this when I'm ready to try to get those patches in.

Just to be clear though, there is a CharDriverState version of the new 
QMP server.  This would be a second option for creating a QMP server and 
it takes a different command line sytnax.

>> 2) Because chardevs don't support multiple connections, we can't 
>> reasonably hook on things like connect/disconnect which means that 
>> fd's sent via SCM_RIGHTs have to be handled in a very special way.  
>> By going outside of the chardev layer, we can let fd's via SCM_RIGHTS 
>> queue up naturally and have getfd/setfd refer to the fd at the top of 
>> the queue.  It makes it quite a bit easier to work with (I believe 
>> Daniel had actually requested this a while ago).
>
> I really don't follow... what's the connection between SCM_RIGHTS and 
> multiple connections?

Monitors have a single fd.  That fd is associated with the monitor and 
lives beyond the length of the connection to the monitor (recall that 
chardevs don't have a notion of connection life cycle).  This means if a 
management tool forgets to do a closefd on an unused fd, there's no easy 
way for QEMU to automatically clean that up.  IOW, a crashed management 
tool == fd leak in QEMU.

>>>> (6) can be started right now.  (1) comes with the QAPI merge.  (2) 
>>>> is pretty easy to do after applying this patch.  (3) is probably 
>>>> something that can be done shortly after (1).  (4) and (5) really 
>>>> require everything but (6) to be in place before we can meaningful 
>>>> do it.
>>>>
>>>> I think we can lay out much of the ground work for this in 0.15 and 
>>>> I think we can have a total conversion realistically for 0.16.  
>>>> That means that by EOY, we could invoke QEMU with no options and do 
>>>> everything through QMP.
>>>
>>> It's something that I've agitated for a long while, but when I see 
>>> all the work needed, I'm not sure it's cost effective.
>>
>> There's a lot of secondary benefits that come from doing this.  QMP 
>> becomes a much stronger interface.  A lot of operations that right 
>> now are only specifiable by the command line become dynamic which 
>> mitigates reboots in the long term. 
>
> Only the hot-pluggable ones.

Yup, but it forces us to treat options that cannot change at runtime as 
special cases which I think is a nice plus.  Customers don't like having 
their guests rebooted during a scheduled downtime so we really ought to 
try to have as many things tunable at runtime as possible.

Regards,

Anthony Liguori