Arch info lost in "info cpus"

Arch info lost in "info cpus"

[Sergio Lopez]

[-- Attachment #1: Type: text/plain, Size: 538 bytes --]

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)?

Thanks,
Sergio.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: Arch info lost in "info cpus"

[Dr. David Alan Gilbert]

* 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)

Dave

> Thanks,
> Sergio.


--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

Re: Arch info lost in "info cpus"

[Viktor Mihajlovski]

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

Re: Arch info lost in "info cpus"

[Eduardo Habkost]

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.

-- 
Eduardo

Re: Arch info lost in "info cpus"

[Dr. David Alan Gilbert]

* 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

Re: Arch info lost in "info cpus"

[Alex Bennée]

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.

>
> Thanks,
> Sergio.


--
Alex Bennée

Re: Arch info lost in "info cpus"

[Sergio Lopez]

[-- 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 --]

Re: Arch info lost in "info cpus"

[Eduardo Habkost]

On Mon, Sep 30, 2019 at 12:22:22PM +0200, Sergio Lopez wrote:
> 
> 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?

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?

-- 
Eduardo

Re: Arch info lost in "info cpus"

[Sergio Lopez]

[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]


Eduardo Habkost <ehabkost@redhat.com> writes:

> On Mon, Sep 30, 2019 at 12:22:22PM +0200, Sergio Lopez wrote:
>> 
>> 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?
>
> 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.



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]