Thomas Huth <th...@redhat.com> writes: > On 11/11/2022 15.53, Markus Armbruster wrote: >> Thomas Huth <th...@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 q-c-l-o.
