qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Viktor Mihajlovski <mihajlov@linux.ibm.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>,
	Sergio Lopez <slp@redhat.com>
Cc: imammedo@redhat.com, tao3.xu@intel.com,
	mihajlov@linux.vnet.ibm.com, qemu-devel@nongnu.org,
	ehabkost@redhat.com
Subject: Re: Arch info lost in "info cpus"
Date: Mon, 30 Sep 2019 14:54:51 +0200	[thread overview]
Message-ID: <ff9deaa5-8bb6-cd58-6921-31729288e448@linux.ibm.com> (raw)
In-Reply-To: <20190930084551.GB2759@work-vm>


On 9/30/19 10:45 AM, 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)
This obviously went by unnoticed back then. Query-cpus-fast should serve
the same purpose as query-cpus there, being less intrusive on the VM and
allow to complete the deprecation process, if this is still wanted. If
not, adding an option that lets hmp 'info cpus' call the old API doesn't
seem unreasonable.

>
> Dave
>
>> Thanks,
>> Sergio.
>
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
>
-- 
Kind Regards,
   Viktor



  reply	other threads:[~2019-09-30 13:36 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 [this message]
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
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=ff9deaa5-8bb6-cd58-6921-31729288e448@linux.ibm.com \
    --to=mihajlov@linux.ibm.com \
    --cc=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).