Re: Arch info lost in "info cpus"

[Sergio Lopez]

Eduardo Habkost <address@hidden> writes:

> On Mon, Sep 30, 2019 at 12:22:22PM +0200, Sergio Lopez wrote:
>> 
>> Alex Bennée <address@hidden> writes:
>> 
>> > Sergio Lopez <address@hidden> 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