qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Markus Armbruster <armbru@redhat.com>
Cc: imammedo@redhat.com, qemu-devel@nongnu.org, Peter Xu <peterx@redhat.com>
Subject: Re: [Qemu-devel] [PATCH 4/6] hmp: Add info commands for preconfig
Date: Fri, 8 Jun 2018 18:18:57 +0100	[thread overview]
Message-ID: <20180608171857.GK2671@work-vm> (raw)
In-Reply-To: <87d0x1p6go.fsf@dusky.pond.sub.org>

* 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:
> >> >> "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.
> 
> Yes, but...
> 
> >                       The requirement is that if a tool needs it then it
> > must be provided in QMP.
> 
> ... it must not do that at the expense of QMP's completeness.
> Permitting that would be a break from how we worked since QMP became
> supported in 0.14 or so.  Seven years, time flies.
> 
> The hard requirement for QMP from day one was "provide everything
> machine clients need".  To avoid speculation and endless arguments about
> what might be needed / not needed, we resolved to approximate this by
> "provide everything, except stuff that's *clearly* of no use to
> machines".  This has been spelled out on this list several times.
> Here are two relatively recent iterations:
> 
> Message-ID: <8737cngvq6.fsf@dusky.pond.sub.org>
> https://lists.gnu.org/archive/html/qemu-devel/2017-04/msg05309.html
> 
> Message-ID: <8760hrxtcn.fsf@dusky.pond.sub.org>
> https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg00247.html
> 
> Quoting the latter:
> 
> In general, functionality available in HMP should also available in QMP.
> Exceptions include functionality that makes no sense in QMP, or is of
> use only for human users.  If you think your command is an exception,
> please explain why in the commit message.
> 
> If it isn't, you need to implement it for QMP (including suitable test
> cases), then rewrite the HMP version to reuse either the QMP command or
> a common core.
> 
> Example for "makes no sense in QMP": setting the current CPU[1], because
> a QMP monitor doesn't have a current CPU.
> 
> Examples for "is of use only for human users": HMP command "help", the
> integrated pocket calculator[2].
> 
> End quote.
> 
> But we're not even arguing about a new HMP command, we're arguing about
> making existing commands available in preconfig state.  I assume that if
> an HMP command is useful in preconfig state, then its QMP buddy is also
> useful there.  I therefore asked you whether their QMP equivalents are
> all available in preconfig state.  The answer I expected was a short
> table of three columns: HMP command you propose to enable, QMP buddy if
> any, whether the QMP buddy is available in preconfig state yes/no.
> Estimated effort: minutes.  What I got instead of this data was an
> argument about fundamental design decisions.  Fine, reexaminating
> fundamentals once in a while isn't a bad idea.  But may I have my data
> now?

I believe that table is in the v3 version patch 5.

Dave

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

  reply	other threads:[~2018-06-08 17:19 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-05 12:26 [Qemu-devel] [PATCH 0/6] Reenable hmp for preconfig mode Dr. David Alan Gilbert (git)
2018-06-05 12:26 ` [Qemu-devel] [PATCH 1/6] hmp: Add flag for preconfig commands Dr. David Alan Gilbert (git)
2018-06-07  8:50   ` Peter Xu
2018-06-07 12:14   ` Markus Armbruster
2018-06-07 12:18     ` Dr. David Alan Gilbert
2018-06-05 12:26 ` [Qemu-devel] [PATCH 2/6] hmp: Allow help on " Dr. David Alan Gilbert (git)
2018-06-07  8:51   ` Peter Xu
2018-06-05 12:26 ` [Qemu-devel] [PATCH 3/6] hmp: Restrict auto-complete in preconfig Dr. David Alan Gilbert (git)
2018-06-07  8:52   ` Peter Xu
2018-06-05 12:26 ` [Qemu-devel] [PATCH 4/6] hmp: Add info commands for preconfig Dr. David Alan Gilbert (git)
2018-06-07  8:49   ` Peter Xu
2018-06-07 12:22     ` Markus Armbruster
2018-06-07 13:45       ` Dr. David Alan Gilbert
2018-06-07 15:12         ` Markus Armbruster
2018-06-07 15:28           ` Dr. David Alan Gilbert
2018-06-08  5:56             ` Markus Armbruster
2018-06-08  8:18               ` Dr. David Alan Gilbert
2018-06-08  9:30                 ` Igor Mammedov
2018-06-08 16:51                 ` Markus Armbruster
2018-06-08 17:18                   ` Dr. David Alan Gilbert [this message]
2018-06-07 15:08       ` Igor Mammedov
2018-06-08  5:41         ` Markus Armbruster
2018-06-07  9:39   ` Igor Mammedov
2018-06-05 12:26 ` [Qemu-devel] [PATCH 5/6] hmp: add exit_preconfig Dr. David Alan Gilbert (git)
2018-06-07  8:53   ` Peter Xu
2018-06-05 12:26 ` [Qemu-devel] [PATCH 6/6] hmp: Allow HMP in preconfig state again Dr. David Alan Gilbert (git)
2018-06-07  8:56   ` Peter Xu
2018-06-07  8:54 ` [Qemu-devel] [PATCH 0/6] Reenable hmp for preconfig mode Peter Xu
2018-06-07  9:00   ` Dr. David Alan Gilbert
2018-06-07  9:05     ` Peter Xu
2018-06-07  9:45   ` Igor Mammedov
2018-06-07 10:02     ` Peter Xu
2018-06-07  9:48 ` Igor Mammedov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180608171857.GK2671@work-vm \
    --to=dgilbert@redhat.com \
    --cc=armbru@redhat.com \
    --cc=imammedo@redhat.com \
    --cc=peterx@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).