From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: imammedo@redhat.com, tao3.xu@intel.com, qemu-devel@nongnu.org,
Sergio Lopez <slp@redhat.com>,
mihajlov@linux.vnet.ibm.com
Subject: Re: Arch info lost in "info cpus"
Date: Wed, 2 Oct 2019 09:06:52 +0100 [thread overview]
Message-ID: <20191002080652.GA2710@work-vm> (raw)
In-Reply-To: <20191001194301.GK4084@habkost.net>
* Eduardo Habkost (ehabkost@redhat.com) wrote:
> On Mon, Sep 30, 2019 at 09:45:51AM +0100, Dr. David Alan Gilbert wrote:
> > * Sergio Lopez (slp@redhat.com) wrote:
> > > 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.
> > >
> > > Is there an alternative way of getting something equivalent to what
> > > "info cpus" provided previously (in 2.10)?
> >
> > Even the qemp equivalent, query-cpus is deprecated.
> > (Although we do call the underlying query-cpus in 'info numa' as well)
>
> Why exactly it has to be deprecated? We have use cases that
> require `query-cpus-fast` to exist, but I don't see why the
> existence of a command that returns extended information is a bad
> thing.
>
> Having a command that synchronizes CPU state is even a
> requirement if we want to eventually implement "info registers"
> using QMP.
Yes, agreed; it was useful to have the non-syncing version
but I don't see a reason to remove the full-fat version.
Dave
> --
> Eduardo
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2019-10-02 8:07 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 [this message]
2019-09-30 9:13 ` Alex Bennée
2019-09-30 10:22 ` Sergio Lopez
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=20191002080652.GA2710@work-vm \
--to=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=mihajlov@linux.vnet.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=slp@redhat.com \
--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 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).