[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: Markus Armbruster
Subject: Re: [PATCH v2] util/qemu-config: Fix "query-command-line-options" to provide the right values
Date: Tue, 15 Nov 2022 08:53:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

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.

Moreover, our needs have long outgrown QemuOpts' design limitations,
which has led to a bunch of bolted-on hacks, none of them represented in

reply via email to

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