Message ID | 20220714150735.1835166-1-berrange@redhat.com |
---|---|
Headers | show |
Series | target: RFC: display deprecation note for '-cpu help' | expand |
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...
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
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)?
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
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?