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

[Anthony Liguori]

On 02/24/2011 10:01 AM, Avi Kivity wrote:
> On 02/24/2011 01:12 AM, Anthony Liguori wrote:
> > > What is the plan from here?
> >
> >
> > 1) Decouple QMP from qemu_machine_init().  This really requires the 
> > introduction of the new QAPI server that exists outside of the 
> > chardev infrastructure since chardevs are currently initialized in 
> > qemu_machine_init().
>
> 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.

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

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

3) By treating QMP as a special case, we don't have to treat chardevs 
overall as a special case.  This feels more right to me although I can't 
say I have a strong opinion formed yet.

> > 2) Make qemu_machine_init() take no parameters and just reference 
> > global state.
> >
> > 3) Teach all QMP functions to behave themselves if called before 
> > qemu_machine_init()
> >
> > 4) Introduce QMP function to call qemu_machine_init()
>
> An alternative is to remove all guest-visible content from 
> qemu_machine_init().  So machine->init() would take no parameters and 
> only build the static devices (power supply?).  Everything else would 
> be hot-plugged (perhaps some would fail if the machine was started - 
> cold-plug only).

All that qemu_machine_init() is is guest-visible content.  That's the 
point of refactoring this.

> > 5) Introduce new command line flag to not automatically call 
> > qemu_machine_init()
> >
> > 6) Convert all command line options to just be QMP function calls
> >
> > (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.  It also lays the ground work for a fully 
decoupled device model whereas the only interface between the devices 
and the outside world is a subset of QMP (think seccomp()).

Whether creating a machine with no command line options is high value is 
probably irrelevant.  I think we want to go in this direction regardless.

Regards,

Anthony Liguori