Thomas Huth <thuth@redhat.com> writes:
On 11/11/2022 15.53, Markus Armbruster wrote:
Thomas Huth <thuth@redhat.com> writes:
The "query-command-line-options" command uses a hand-crafted list
of options that should be returned for the "machine" parameter.
This is pretty much out of sync with reality, for example settings
like "kvm_shadow_mem" or "accel" are not parameters for the machine
anymore. Also, there is no distinction between the targets here, so
e.g. the s390x-specific values like "loadparm" in this list also
show up with the other targets like x86_64.
Let's fix this now by geting rid of the hand-crafted list and by
querying the properties of the machine classes instead to assemble
the list.
Do we know what uses this command, and how these users are
inconvenienced by the flaw you're fixing?
I'm asking because the command is pretty much out of sync with reality
by (mis-)design.
libvirt apparently queries this data (see the various
tests/qemucapabilitiesdata/*.replies files in their repository), but since
it's so much out-of-sync with reality, it's not of a big use there yet.
See for example here:
https://lists.gnu.org/archive/html/qemu-devel/2021-12/msg00581.html
If we finally fix this problem with "query-command-line-options" in QEMU, it
should be much easier to deprecate -no-hpet in QEMU, too.
For a value of "fix". While we can fix certain concrete issues with
q-c-l-o, which may be wortwhile, the overarching issue is (in my
opinion) unfixable: it can only tell us about QemuOpts.
QemuOpts is only part of the truth. Last time I checked, it worked for
one out of five CLI options.