From: Sergio Lopez <slp@redhat.com>
To: alex.bennee@linaro.org
Cc: ehabkost@redhat.com, tao3.xu@intel.com, qemu-devel@nongnu.org,
mihajlov@linux.vnet.ibm.com, imammedo@redhat.com,
dgilbert@redhat.com
Subject: Re: Arch info lost in "info cpus"
Date: Mon, 30 Sep 2019 12:22:22 +0200 [thread overview]
Message-ID: <878sq6hyn5.fsf@redhat.com> (raw)
In-Reply-To: <87lfu6kuyo.fsf@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1034 bytes --]
Alex Bennée <alex.bennee@linaro.org> writes:
> Sergio Lopez <slp@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?
Thanks,
Sergio.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2019-09-30 10:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-30 7:54 Arch info lost in "info cpus" Sergio Lopez
2019-09-30 8:45 ` Dr. David Alan Gilbert
2019-09-30 12:54 ` Viktor Mihajlovski
2019-10-01 19:43 ` Eduardo Habkost
2019-10-02 8:06 ` Dr. David Alan Gilbert
2019-09-30 9:13 ` Alex Bennée
2019-09-30 10:22 ` Sergio Lopez [this message]
2019-09-30 21:05 ` Eduardo Habkost
2019-10-01 7:58 ` Sergio Lopez
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=878sq6hyn5.fsf@redhat.com \
--to=slp@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=mihajlov@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=tao3.xu@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.