Re: Arch info lost in "info cpus"
* Eduardo Habkost (ehabk...@redhat.com) wrote: > On Mon, Sep 30, 2019 at 09:45:51AM +0100, Dr. David Alan Gilbert wrote: > > * Sergio Lopez (s...@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 / dgilb...@redhat.com / Manchester, UK
Re: Arch info lost in "info cpus"
On Mon, Sep 30, 2019 at 09:45:51AM +0100, Dr. David Alan Gilbert wrote: > * Sergio Lopez (s...@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"
Eduardo Habkost writes: > On Mon, Sep 30, 2019 at 12:22:22PM +0200, Sergio Lopez wrote: >> >> Alex Bennée writes: >> >> > Sergio Lopez 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
Re: Arch info lost in "info cpus"
On Mon, Sep 30, 2019 at 12:22:22PM +0200, Sergio Lopez wrote: > > Alex Bennée writes: > > > Sergio Lopez 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"
On 9/30/19 10:45 AM, Dr. David Alan Gilbert wrote: > * Sergio Lopez (s...@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 / dgilb...@redhat.com / Manchester, UK > -- Kind Regards, Viktor
Re: Arch info lost in "info cpus"
Alex Bennée writes: > Sergio Lopez 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. signature.asc Description: PGP signature
Re: Arch info lost in "info cpus"
Sergio Lopez 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 (s...@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 / dgilb...@redhat.com / Manchester, UK
Arch info lost in "info cpus"
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. signature.asc Description: PGP signature
