[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
Re: [PATCH v2] util/qemu-config: Fix "query-command-line-options" to provide the right values
Tue, 15 Nov 2022 10:54:56 +0100
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Thomas Huth <email@example.com> writes:
> On 15/11/2022 08.53, Markus Armbruster wrote:
>> Thomas Huth <firstname.lastname@example.org> writes:
>>> On 11/11/2022 15.53, Markus Armbruster wrote:
>>>> Thomas Huth <email@example.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?
I'm not objecting to fixing "concrete issues with q-c-l-o, which may be
worthwhile", such as this patch, as long as something actually makes use
of the fixes, now or in the immediate future.