mbox series

[0/3] target: RFC: display deprecation note for '-cpu help'

Message ID 20220714150735.1835166-1-berrange@redhat.com
Headers show
Series target: RFC: display deprecation note for '-cpu help' | expand

Message

Daniel P. Berrangé July 14, 2022, 3:07 p.m. UTC
When querying '-cpu help' there is no presentation of fact that a
CPU may be deprecated. The user just has to try it and see if they
get a depecation message at runtime.  The QMP command for querying
CPUs report a deprecation bool flag, but not the explanatory
reason.

The Icelake-Client CPU (removed in 6df39f5e583ca0f67bd934d1327f9ead2e3bd49c)
handled this by modifying the '.notes' section to add the word
'deprecated':

            {
                .version = 2,
                .note = "no TSX, deprecated",
                .alias = "Icelake-Client-noTSX",
                .props = (PropValue[]) {
                    { "hle", "off" },
                    { "rtm", "off" },
                    { /* end of list */ }
                },
            },

This relies on the person deprecating the CPU to remember to do this,
and is redundant when this info is already expressed in the
'.deprecation_note' field.

This short series suggests just modifying the '-cpu help'
formatter so that it displays the full deprecation message

eg

$ qemu-system-x86_64 -cpu help:
Available CPUs:
x86 486                   (alias configured by machine type) (deprecated: use at least 'Nehalem' / 'Opteron_G4', or 'host' / 'max')

I wonder if this is too verbose, and we should just do a
concise flag like approach, similar to QMP:

$ qemu-system-x86_64 -cpu help:
Available CPUs:
x86 486                   (alias configured by machine type) (deprecated)

leaving the full message to be displayed at runtime ? I'm slightly
inclined to the simpler more concise output.

This series touched x86_64, s390x, and aarch64 because that's all I
personally needed from a downstream POV, but any & all of the targets
would benefit from this. They have each implemneted the '-cpu help'
logic independantly though, and unifying that code is not entirely
straightforward.

Daniel P. Berrangé (3):
  target/i386: display deprecation note in '-cpu help'
  target/s390x: display deprecation note in '-cpu help'
  target/arm: display deprecation note in '-cpu help'

 target/arm/helper.c       | 10 +++++++++-
 target/i386/cpu.c         | 13 ++++++++++++-
 target/s390x/cpu_models.c | 28 +++++++++++++++++++++++-----
 3 files changed, 44 insertions(+), 7 deletions(-)

Comments

Cornelia Huck July 15, 2022, 8:45 a.m. UTC | #1
On Thu, Jul 14 2022, Daniel P. Berrangé <berrange@redhat.com> wrote:

> When querying '-cpu help' there is no presentation of fact that a
> CPU may be deprecated. The user just has to try it and see if they
> get a depecation message at runtime.  The QMP command for querying
> CPUs report a deprecation bool flag, but not the explanatory
> reason.
>
> The Icelake-Client CPU (removed in 6df39f5e583ca0f67bd934d1327f9ead2e3bd49c)
> handled this by modifying the '.notes' section to add the word
> 'deprecated':
>
>             {
>                 .version = 2,
>                 .note = "no TSX, deprecated",
>                 .alias = "Icelake-Client-noTSX",
>                 .props = (PropValue[]) {
>                     { "hle", "off" },
>                     { "rtm", "off" },
>                     { /* end of list */ }
>                 },
>             },
>
> This relies on the person deprecating the CPU to remember to do this,
> and is redundant when this info is already expressed in the
> '.deprecation_note' field.
>
> This short series suggests just modifying the '-cpu help'
> formatter so that it displays the full deprecation message
>
> eg
>
> $ qemu-system-x86_64 -cpu help:
> Available CPUs:
> x86 486                   (alias configured by machine type) (deprecated: use at least 'Nehalem' / 'Opteron_G4', or 'host' / 'max')
>
> I wonder if this is too verbose, and we should just do a
> concise flag like approach, similar to QMP:
>
> $ qemu-system-x86_64 -cpu help:
> Available CPUs:
> x86 486                   (alias configured by machine type) (deprecated)
>
> leaving the full message to be displayed at runtime ? I'm slightly
> inclined to the simpler more concise output.

The good thing about the longer output is that the user gets the full
information right from the start, and does not need to dig around and
figure out why it is deprecated, and what to use instead. That said, if
we have very verbose deprecation notes, the output may get a bit
cluttered. I think I slightly prefer the verbose output.

>
> This series touched x86_64, s390x, and aarch64 because that's all I
> personally needed from a downstream POV, but any & all of the targets
> would benefit from this. They have each implemneted the '-cpu help'
> logic independantly though, and unifying that code is not entirely
> straightforward.

It seems that any arch that does not use a very simple output has chosen
a different format...
Thomas Huth July 18, 2022, 9:25 a.m. UTC | #2
On 14/07/2022 17.07, Daniel P. Berrangé wrote:
> When querying '-cpu help' there is no presentation of fact that a
> CPU may be deprecated. The user just has to try it and see if they
> get a depecation message at runtime.  The QMP command for querying
> CPUs report a deprecation bool flag, but not the explanatory
> reason.
> 
> The Icelake-Client CPU (removed in 6df39f5e583ca0f67bd934d1327f9ead2e3bd49c)
> handled this by modifying the '.notes' section to add the word
> 'deprecated':
> 
>              {
>                  .version = 2,
>                  .note = "no TSX, deprecated",
>                  .alias = "Icelake-Client-noTSX",
>                  .props = (PropValue[]) {
>                      { "hle", "off" },
>                      { "rtm", "off" },
>                      { /* end of list */ }
>                  },
>              },
> 
> This relies on the person deprecating the CPU to remember to do this,
> and is redundant when this info is already expressed in the
> '.deprecation_note' field.
> 
> This short series suggests just modifying the '-cpu help'
> formatter so that it displays the full deprecation message
> 
> eg
> 
> $ qemu-system-x86_64 -cpu help:
> Available CPUs:
> x86 486                   (alias configured by machine type) (deprecated: use at least 'Nehalem' / 'Opteron_G4', or 'host' / 'max')
> 
> I wonder if this is too verbose, and we should just do a
> concise flag like approach, similar to QMP:
> 
> $ qemu-system-x86_64 -cpu help:
> Available CPUs:
> x86 486                   (alias configured by machine type) (deprecated)
> 
> leaving the full message to be displayed at runtime ? I'm slightly
> inclined to the simpler more concise output.

I'd prefer to keep it short here and just write "deprecated" without the 
reason. Otherwise this will overflow the lines and break the readability of 
the output. And it's also what we're also doing for "-machine", e.g.:

$ ./qemu-system-ppc64 -M help | grep deprecate
taihu                taihu (deprecated)
$ ./qemu-system-ppc64 -M taihu
qemu-system-ppc64: warning: Machine type 'taihu' is deprecated: incomplete, 
use 'ref405ep' instead

  Thomas
Cornelia Huck July 18, 2022, 9:37 a.m. UTC | #3
On Mon, Jul 18 2022, Thomas Huth <thuth@redhat.com> wrote:

> On 14/07/2022 17.07, Daniel P. Berrangé wrote:
>> $ qemu-system-x86_64 -cpu help:
>> Available CPUs:
>> x86 486                   (alias configured by machine type) (deprecated: use at least 'Nehalem' / 'Opteron_G4', or 'host' / 'max')
>> 
>> I wonder if this is too verbose, and we should just do a
>> concise flag like approach, similar to QMP:
>> 
>> $ qemu-system-x86_64 -cpu help:
>> Available CPUs:
>> x86 486                   (alias configured by machine type) (deprecated)
>> 
>> leaving the full message to be displayed at runtime ? I'm slightly
>> inclined to the simpler more concise output.
>
> I'd prefer to keep it short here and just write "deprecated" without the 
> reason. Otherwise this will overflow the lines and break the readability of 
> the output. And it's also what we're also doing for "-machine", e.g.:
>
> $ ./qemu-system-ppc64 -M help | grep deprecate
> taihu                taihu (deprecated)
> $ ./qemu-system-ppc64 -M taihu
> qemu-system-ppc64: warning: Machine type 'taihu' is deprecated: incomplete, 
> use 'ref405ep' instead

Ok, following what -machine does is certainly a good point.

Is it easy enough the figure out the deprecation note? I think you
either have to actually start something with the deprecated entity, or
use qmp (which is not that straightforward)?
Daniel P. Berrangé July 18, 2022, 9:46 a.m. UTC | #4
On Mon, Jul 18, 2022 at 11:37:35AM +0200, Cornelia Huck wrote:
> On Mon, Jul 18 2022, Thomas Huth <thuth@redhat.com> wrote:
> 
> > On 14/07/2022 17.07, Daniel P. Berrangé wrote:
> >> $ qemu-system-x86_64 -cpu help:
> >> Available CPUs:
> >> x86 486                   (alias configured by machine type) (deprecated: use at least 'Nehalem' / 'Opteron_G4', or 'host' / 'max')
> >> 
> >> I wonder if this is too verbose, and we should just do a
> >> concise flag like approach, similar to QMP:
> >> 
> >> $ qemu-system-x86_64 -cpu help:
> >> Available CPUs:
> >> x86 486                   (alias configured by machine type) (deprecated)
> >> 
> >> leaving the full message to be displayed at runtime ? I'm slightly
> >> inclined to the simpler more concise output.
> >
> > I'd prefer to keep it short here and just write "deprecated" without the 
> > reason. Otherwise this will overflow the lines and break the readability of 
> > the output. And it's also what we're also doing for "-machine", e.g.:
> >
> > $ ./qemu-system-ppc64 -M help | grep deprecate
> > taihu                taihu (deprecated)
> > $ ./qemu-system-ppc64 -M taihu
> > qemu-system-ppc64: warning: Machine type 'taihu' is deprecated: incomplete, 
> > use 'ref405ep' instead
> 
> Ok, following what -machine does is certainly a good point.

Yes, I should have thought to check what -machine does, it makese
sense to be consistent.

> Is it easy enough the figure out the deprecation note? I think you
> either have to actually start something with the deprecated entity, or
> use qmp (which is not that straightforward)?

QMP doesn't tell you the note, just a boolean deprecation flag. It is
only printed on startup only right now.

In the context of libvirt what happens is that libvirt can report that
something is deprecated (based on the QMP response). If you go ahead
and use it anyway, you'll get the deprecation message in the logfile
for the VM, and the VM gets marked tainted by libvirt, which serves
as a guide to look in the logfile.

With regards,
Daniel
Cornelia Huck July 18, 2022, 9:58 a.m. UTC | #5
On Mon, Jul 18 2022, Daniel P. Berrangé <berrange@redhat.com> wrote:

> On Mon, Jul 18, 2022 at 11:37:35AM +0200, Cornelia Huck wrote:
>> Is it easy enough the figure out the deprecation note? I think you
>> either have to actually start something with the deprecated entity, or
>> use qmp (which is not that straightforward)?
>
> QMP doesn't tell you the note, just a boolean deprecation flag. It is
> only printed on startup only right now.
>
> In the context of libvirt what happens is that libvirt can report that
> something is deprecated (based on the QMP response). If you go ahead
> and use it anyway, you'll get the deprecation message in the logfile
> for the VM, and the VM gets marked tainted by libvirt, which serves
> as a guide to look in the logfile.

Hm... so, a user who notes via -help that 'foo' is deprecated does not
really have a good way to figure out what they should use instead, other
than actually trying to use 'foo'? Is that a use case worth spending
some effort on, or do we consider it more of a niche case?