Re: [Qemu-devel] Re: KVM call minutes for June 8

[Luiz Capitulino]

On Tue, 08 Jun 2010 11:01:19 -0500
Anthony Liguori <address@hidden> wrote:

> On 06/08/2010 10:05 AM, Chris Wright wrote:

[...]

> > migration events?
> > - QMP (wire protocol) has nice async events
> >    - QError reasonable
> >    - migration is async command, can complete w/ error or success
> > - QMP broken for error
> >    - need context for error, default is monitor, but async command
> >    - redo qerror_report, propagate error (or always have error context
> >      available)
> > - monitor and qmp done w/ same dispatch functions
> >    - should do monitor in terms of qmp
> >      - every qerror replacing monitor printf error
> >        - ends up not sharing enough ($foo not found, where $foo is 
> > contextual)
> > - async command (pass in command completion)
> > - may have to do limited (throw away for 0.13 and redo properly for 0.14)
> > - anthony has a (not fully working) tree, and will document direction on 
> > wiki
> >   

 Nice summary. 
> 
> http://wiki.qemu.org/Features/QMP2

 Nice page, except that its original name raised the question whether
current QMP was going to be thrown away and done from scratch :-)

 I agree on most points and yes, we have issues with QError and async
commands. However, as we talked by IRC, I think we should define what's
blocker for 0.13 and what's ok to be postponed.

 IMO, there are two classes of problems that have to be fixed for 0.13:

 1. Client visible changes
 2. Any issue that makes QMP not work as specified by its documentation

 Async commands is item 2, but it doesn't look that serious to me provided
that, as you said, we ensure that commands don't run in parallel and that
query-balloon (our only async command) doesn't hit the issue.

 The decoupling of QMP and HMP is something I really wanted to do, but this
is clearly not 0.13 material. Also note that the monitor state before QMP
was quite horrible, it's slightly better now, but main point is: we would
not have QMP today if we would fix/cleanup all the problems we've found,
specially because some problems span the monitor code base.

 Now, QError.

 This is something I think we should fix for 0.13. However, I still don't
know how to get it right: most of what you say in the wiki page has already
been discussed before.

 For example, you suggest the error object should be returned, this is
probably a requirement to have async commands working, but this thread
explains the problems we had with that:

 http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg00818.html

 Another issue is that QErrors are getting too specific. I see two problems
here, first how errors should be done and how to map errno properly, also
already discussed:

 http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg00314.html

 Finally, sometimes handler A and handler B can share the error class but not
the error context. I can't locate a good example right now, but this becomes
evident if you have a 1:1 mapping between QError and errno (eg, EINVAL can be
anything), so it's hard to share errors in this case and we end up creating
new ones.