Re: [Qemu-devel] [PATCH 4/6] hmp: Add info commands for preconfig

[Igor Mammedov]

On Fri, 8 Jun 2018 09:18:46 +0100
"Dr. David Alan Gilbert" <address@hidden> wrote:

> * Markus Armbruster (address@hidden) wrote:
> > "Dr. David Alan Gilbert" <address@hidden> writes:
> >   
> > > * Markus Armbruster (address@hidden) wrote:  
> > >> "Dr. David Alan Gilbert" <address@hidden> writes:
> > >>   
> > >> > * Markus Armbruster (address@hidden) wrote:  
> > >> >> Peter Xu <address@hidden> writes:
> > >> >>   
> > >> >> > On Tue, Jun 05, 2018 at 01:26:34PM +0100, Dr. David Alan Gilbert 
> > >> >> > (git) wrote:  
> > >> >> >> From: "Dr. David Alan Gilbert" <address@hidden>
> > >> >> >> 
> > >> >> >> Allow a bunch of the info commands to be used in preconfig.
> > >> >> >> Could probably add most of them.  
> > >> >> >
> > >> >> > I guess some of them may not work yet during preconfig.  E.g.:
> > >> >> >
> > >> >> > $ ./x86_64-softmmu/qemu-system-x86_64 -preconfig -monitor stdio
> > >> >> > QEMU 2.12.50 monitor - type 'help' for more information
> > >> >> > (qemu) info mtree
> > >> >> > address-space: memory
> > >> >> >   0000000000000000-ffffffffffffffff (prio 0, i/o): system
> > >> >> >
> > >> >> > address-space: I/O
> > >> >> >   0000000000000000-000000000000ffff (prio 0, i/o): io
> > >> >> >
> > >> >> > But it's fine to enable that I guess.
> > >> >> >
> > >> >> > (Which "info" command would you want to use during preconfig?)
> > >> >> >  
> > >> >> >> 
> > >> >> >> Signed-off-by: Dr. David Alan Gilbert <address@hidden>  
> > >> >> >
> > >> >> > Reviewed-by: Peter Xu <address@hidden>  
> > >> >> 
> > >> >> The reason for having -preconfig is us despairing of making -S do the
> > >> >> right thing.  We'd have to *understand* the tangled mess that is our
> > >> >> startup, and rearrange it so QMP becomes available early enough for
> > >> >> configuring NUMA (and other things), yet late enough for everything to
> > >> >> work.
> > >> >> 
> > >> >> -preconfig is a cheap hack to avoid this headache, by bypassing almost
> > >> >> all of "everything".
> > >> >> 
> > >> >> Now you bring back some of "everything".  Dangerous.  You better show 
> > >> >> it
> > >> >> actually works.  Until you do:
> > >> >> 
> > >> >> NAK  
> > >> >
> > >> > Well I did test each command in here to make sure it didn't
> > >> > crash/produce complete junk; but here's the output with the v2 of this
> > >> > patch that Igor R-b:  
> > >> [...]
> > >> 
> > >> For the sake of the argument, let's assume these commands all work in
> > >> preconfig state.  Are their QMP equivalents all available in preconfig
> > >> state?  
> > >
> > > That I don't know; I was happy to fix my list to the ones
> > > Igor recommended.  If you object to some particular entries I'll
> > > be happy to change them.  
> > 
> > HMP must not provide more functionality than QMP.  Specifically, we may
> > provide "info FOO" only when we also provide query-FOO.
> >
> > There are exceptions to this rule.  I don't think they apply here.  I'm
> > prepared to discuss them, of course.  
> 
> No, that's strictly not true;  HMP can provide anything that helps
> a human debug stuff.  The requirement is that if a tool needs it then it
> must be provided in QMP.
> 
> > I wish there was a way to automate "provide command in HMP when its
> > buddy is available in QMP", but since the buddies are only connected by
> > code, that seems infeasible.
> > 
> > Without such automation, the two sets of available commands need to be
> > kept consistent manually.  The larger they are, the more of a bother.
> > 
> > Bother is fine when it provides commensurate value to users.  Options in
> > increasing order of value provided:
> > 
> > (1) HMP becomes ready only after we exit preconfig state (what I
> >     proposed in Message-ID: <address@hidden>.
> >
> > (2) HMP provides help, quit, exit-preconfig.
> > 
> > (3) HMP provides (a subset of) the commands QMP provides.
> > 
> > I figure the maintenance cost of (1) and (2) will be negligible, but (3)
> > could be a drag.  Are you sure it's worthwhile?  
>
> 
> I'm not prepared to restrict to (2), and I'm not prepared to restrict
> HMP to a subset of QMP;  As I said previously, if there's a command that
> you think is incorrect/broken that I've enabled then I'm happy to
> remove it.
I'd prefer #3 if we going to expose HMP at all or #1.

#3 would allow testing via HMP for those who can't use qmp-shell.
we can trim HMP list to allowed-preconfig commands or audit respective
QMP variants (they should work without changes) and flag them with
allowed-preconfig. 

> 
> Dave
> 
> --
> Dr. David Alan Gilbert / address@hidden / Manchester, UK
>