| Message ID | 20180605122636.33654-5-dgilbert@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | Reenable hmp for preconfig mode | expand |
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>
On Tue, 5 Jun 2018 13:26:34 +0100 "Dr. David Alan Gilbert (git)" <dgilbert@redhat.com> 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. > > Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> > --- > hmp-commands-info.hx | 9 +++++++++ > hmp-commands.hx | 1 + > 2 files changed, 10 insertions(+) > > diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx > index ddfcd5adcc..00735e7d1c 100644 > --- a/hmp-commands-info.hx > +++ b/hmp-commands-info.hx > @@ -19,6 +19,7 @@ ETEXI > .params = "", > .help = "show the version of QEMU", > .cmd = hmp_info_version, > + .flags = "p", > }, > > STEXI > @@ -33,6 +34,7 @@ ETEXI > .params = "", > .help = "show the network state", > .cmd = hmp_info_network, > + .flags = "p", output seems to refer to frontend devices, so we probably should skip this one > }, > > STEXI > @@ -47,6 +49,7 @@ ETEXI > .params = "", > .help = "show the character devices", > .cmd = hmp_info_chardev, > + .flags = "p", > }, > > STEXI > @@ -62,6 +65,7 @@ ETEXI > .help = "show info of one block device or all block devices " > "(-n: show named nodes; -v: show details)", > .cmd = hmp_info_block, > + .flags = "p", > }, Devices (frontends) are processed after preconfig point, so there isn't point in enabling this. At least until we could instantiate devices at that time. > > STEXI > @@ -151,6 +155,7 @@ ETEXI > .params = "", > .help = "show infos for each CPU", > .cmd = hmp_info_cpus, > + .flags = "p", > }, this command probably shouldn't be enabled, there can't be any CPUs at this point yet. > > STEXI > @@ -165,6 +170,7 @@ ETEXI > .params = "", > .help = "show the command line history", > .cmd = hmp_info_history, > + .flags = "p", > }, > > STEXI > @@ -255,6 +261,7 @@ ETEXI > .help = "show memory tree (-f: dump flat view for address spaces;" > "-d: dump dispatch tree, valid with -f only)", > .cmd = hmp_info_mtree, > + .flags = "p", > }, probably we should skip this one as well > > STEXI > @@ -399,6 +406,7 @@ ETEXI > .params = "", > .help = "show the current VM status (running|paused)", > .cmd = hmp_info_status, > + .flags = "p", > }, > > STEXI > @@ -829,6 +837,7 @@ ETEXI > .params = "", > .help = "Show information about hotpluggable CPUs", > .cmd = hmp_hotpluggable_cpus, > + .flags = "p", > }, > > STEXI > diff --git a/hmp-commands.hx b/hmp-commands.hx > index 8bf590ae4b..dc82ed526f 100644 > --- a/hmp-commands.hx > +++ b/hmp-commands.hx > @@ -1856,6 +1856,7 @@ ETEXI > .help = "show various information about the system state", > .cmd = hmp_info_help, > .sub_table = info_cmds, > + .flags = "p", > }, > > STEXI in addition to above we should be able to handle at preconfig time: info memdev info name info numa info qom-tree info usbhost info uuid info iothreads
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
* 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: [dgilbert@dgilbert-t530 try]$ ./x86_64-softmmu/qemu-system-x86_64 -nographic -preconfig (qemu) (qemu) (qemu) help info info chardev -- show the character devices info history -- show the command line history info hotpluggable-cpus -- Show information about hotpluggable CPUs info iothreads -- show iothreads info memdev -- show memory backends info name -- show the current VM name info numa -- show NUMA information info qom-tree [path] -- show QOM composition tree info status -- show the current VM status (running|paused) info usbhost -- show host USB devices info uuid -- show the current VM UUID info version -- show the version of QEMU (qemu) info chardev serial0: filename=mux serial0-base: filename=stdio parallel0: filename=null (qemu) info history 0: 'help info' 1: 'info chardev' 2: 'info history' (qemu) info hotpluggable-cpus Hotpluggable CPUs: type: "qemu64-x86_64-cpu" vcpus_count: "1" CPUInstance Properties: socket-id: "0" core-id: "0" thread-id: "0" (qemu) info iothreads (qemu) info memdev (qemu) info name (qemu) info numa 0 nodes (qemu) info qom-tree /machine (pc-i440fx-3.0-machine) /peripheral (container) /peripheral-anon (container) /unattached (container) /system[0] (qemu:memory-region) /io[0] (qemu:memory-region) (qemu) info status VM status: paused (preconfig) (qemu) info usbhost Bus 2, Addr 3, Port 1.5, Speed 1.5 Mb/s Class 00: USB device 093a:2510 Bus 1, Addr 3, Port 1.6, Speed 480 Mb/s Class ef: USB device 5986:02d2 Bus 3, Addr 2, Port 1, Speed 1.5 Mb/s Class 00: USB device 0d3d:0001 (qemu) info uuid 00000000-0000-0000-0000-000000000000 (qemu) info version 2.12.50v2.12.0-1074-gfbb4dcae3a (qemu) Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
On Thu, 07 Jun 2018 14:22:34 +0200 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. We solve concrete NUMA problem at -S time as was demonstrated by thread: "RFC v2 0/4] enable numa configuration before machine is running from HMP/QMP" were pros and cons are were summarized. But that won't scale to other things. > -preconfig is a cheap hack to avoid this headache, by bypassing almost > all of "everything". hack should allow to move configuration steps to early stage one by one until the point we could obsolete -S (from configuration point) without breaking current -S users and clean up start up mess in process. > Now you bring back some of "everything". Dangerous. You better show it > actually works. Until you do: Tested v2, works as expected so far. > > NAK >
"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?
* 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. Dave -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
Igor Mammedov <imammedo@redhat.com> writes: > On Thu, 07 Jun 2018 14:22:34 +0200 > 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. > We solve concrete NUMA problem at -S time as was demonstrated by thread: > "RFC v2 0/4] enable numa configuration before machine is running from HMP/QMP" > were pros and cons are were summarized. But that won't scale to other things. > >> -preconfig is a cheap hack to avoid this headache, by bypassing almost >> all of "everything". > hack should allow to move configuration steps to early stage one by one > until the point we could obsolete -S (from configuration point) > without breaking current -S users and clean up start up mess in process. Sometimes a hack is the only practical way forward. >> Now you bring back some of "everything". Dangerous. You better show it >> actually works. Until you do: > Tested v2, works as expected so far. See my reply to Dave. >> >> NAK >>
"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. 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?
* 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
On Fri, 8 Jun 2018 09:18:46 +0100 "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote: > * 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. 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 / dgilbert@redhat.com / Manchester, UK >
"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? [...]
* 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
diff --git a/hmp-commands-info.hx b/hmp-commands-info.hx index ddfcd5adcc..00735e7d1c 100644 --- a/hmp-commands-info.hx +++ b/hmp-commands-info.hx @@ -19,6 +19,7 @@ ETEXI .params = "", .help = "show the version of QEMU", .cmd = hmp_info_version, + .flags = "p", }, STEXI @@ -33,6 +34,7 @@ ETEXI .params = "", .help = "show the network state", .cmd = hmp_info_network, + .flags = "p", }, STEXI @@ -47,6 +49,7 @@ ETEXI .params = "", .help = "show the character devices", .cmd = hmp_info_chardev, + .flags = "p", }, STEXI @@ -62,6 +65,7 @@ ETEXI .help = "show info of one block device or all block devices " "(-n: show named nodes; -v: show details)", .cmd = hmp_info_block, + .flags = "p", }, STEXI @@ -151,6 +155,7 @@ ETEXI .params = "", .help = "show infos for each CPU", .cmd = hmp_info_cpus, + .flags = "p", }, STEXI @@ -165,6 +170,7 @@ ETEXI .params = "", .help = "show the command line history", .cmd = hmp_info_history, + .flags = "p", }, STEXI @@ -255,6 +261,7 @@ ETEXI .help = "show memory tree (-f: dump flat view for address spaces;" "-d: dump dispatch tree, valid with -f only)", .cmd = hmp_info_mtree, + .flags = "p", }, STEXI @@ -399,6 +406,7 @@ ETEXI .params = "", .help = "show the current VM status (running|paused)", .cmd = hmp_info_status, + .flags = "p", }, STEXI @@ -829,6 +837,7 @@ ETEXI .params = "", .help = "Show information about hotpluggable CPUs", .cmd = hmp_hotpluggable_cpus, + .flags = "p", }, STEXI diff --git a/hmp-commands.hx b/hmp-commands.hx index 8bf590ae4b..dc82ed526f 100644 --- a/hmp-commands.hx +++ b/hmp-commands.hx @@ -1856,6 +1856,7 @@ ETEXI .help = "show various information about the system state", .cmd = hmp_info_help, .sub_table = info_cmds, + .flags = "p", }, STEXI