[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] util/qemu-config: Fix "query-command-line-options" to pro

From: Thomas Huth
Subject: Re: [PATCH v2] util/qemu-config: Fix "query-command-line-options" to provide the right values
Date: Tue, 15 Nov 2022 09:05:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0

On 15/11/2022 08.53, Markus Armbruster wrote:
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:


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.

Well, that's another problem. For this patch here, can we please focus on getting rid of that stupid hard-coded and outdated list in our source code? Or do you have something better almost ready that will replace this stuff in the very near future?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]