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

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Markus Armbruster (armbru@redhat.com) wrote:
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
> 
> > * Markus Armbruster (armbru@redhat.com) wrote:
> >> "Dr. David Alan Gilbert" <dgilbert@redhat.com> writes:
> >> 
> >> > * Markus Armbruster (armbru@redhat.com) wrote:
> >> >> Peter Xu <peterx@redhat.com> writes:
> >> >> 
> >> >> > On Tue, Jun 05, 2018 at 01:26:34PM +0100, Dr. David Alan Gilbert (git) wrote:
> >> >> >> From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> >> >> >> 
> >> >> >> 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 <dgilbert@redhat.com>
> >> >> >
> >> >> > Reviewed-by: Peter Xu <peterx@redhat.com>
> >> >> 
> >> >> 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: <87603cxob9.fsf@dusky.pond.sub.org>.
>
> (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.

Dave

--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK