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

[Anthony Liguori]

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