Eduardo Habkost <ehabk...@redhat.com> writes: > On Mon, Sep 30, 2019 at 12:22:22PM +0200, Sergio Lopez wrote: >> >> Alex Bennée <alex.ben...@linaro.org> writes: >> >> > Sergio Lopez <s...@redhat.com> writes: >> > >> >> Hi, >> >> >> >> Commit 137b5cb6ab565cb3781d5337591e155932b4230e (hmp: change >> >> hmp_info_cpus to use query-cpus-fast) updated the "info cpus" commit to >> >> make it more lightweight, but also removed the ability to get the >> >> architecture specific status of each vCPU. >> >> >> >> This information was really useful to diagnose certain Guest issues, >> >> without the need of using GDB, which is more intrusive and requires >> >> enabling it in advance. >> > >> > You can always enable the gdbserver from the HMP when you need it. >> > >> >> Is there an alternative way of getting something equivalent to what >> >> "info cpus" provided previously (in 2.10)? >> > >> > info registers >> > >> > should give you a full dump of the CPU state including the PC. >> > >> >> Both methods are less convenient that what we had before. Perhaps it'd >> be reasonable adding a flag to "info cpus" to give users the options of >> having the same behavior as before? > > Is "info registers -a" less convenient because it prints too much > information, or because it doesn't print the active CPU indicator > and thread_id?
A bit of both. Previously, "info cpus" gave you the PC, thread_id, and whether the CPU is halted or not, which is just enough information to have an initial idea of the VM's and Guest's status at a quick glance. You can even call it multiple times to see how the CPUs were progressing. This came specially useful when debugging boot hangs. I mean, as for myself, I can definitely work with "info registers -a". But I would find hard explaining users why the original functionality of "info cpus" was lost. Cheers, Sergio.
signature.asc
Description: PGP signature
