query-command-line-options (was: [PATCH 1/7] qemu: capabilities: Introduce QEMU_CAPS_MACHINE_ACPI)

query-command-line-options (was: [PATCH 1/7] qemu: capabilities: Introduce QEMU_CAPS_MACHINE_ACPI)

[Markus Armbruster]

[Resent with cc: qemu-devel and adjusted subject, sorry for the noise]

abologna at redhat.com (Andrea Bolognani) writes:

> On Mon, Feb 27, 2023 at 06:25:23PM +0100, Peter Krempa wrote:
>> On Mon, Feb 27, 2023 at 08:44:57 -0800, Andrea Bolognani wrote:
>> > This looks like you're checking whether -acpi itself exists as a
>> > top-level option. Which it doesn't, but -no-acpi does and yet it
>> > doesn't seem to be advertised in the output of
>> > query-command-line-options?
>>
>> Well, it actually does exist in the output of
>> query-command-line-options, but I have no idea what it means:
>>
>> virsh qemu-monitor-command --pretty cd query-command-line-options | jq .return[].option
>>
>> One of the options is "acpi".
>
> Right, I've seen that. What I wanted to say if that passing it to
> QEMU results in an error:
>
>   $ qemu-system-x86_64 -acpi
>   qemu-system-x86_64: -acpi: invalid option
>
> So it's not really an option, despite being advertised as such. And
> on the opposite end of the spectrum we have -no-acpi, which *does*
> work when passed to QEMU but is nowhere to be found in the JSON
> document returned by query-command-line-options.
>
>> > Basically it looks like there are some serious introspection
>> > shenanigans going on, and I'm not sure we can actually reliably
>> > detect whether -machine acpi can be used until your QEMU patch has
>> > been merged.
>> >
>> > Or I might just have missed something obvious! In which case, please
>> > let me know what it is :)
>>
>> I have no idea what the 'acpi' option does but it certainly mislead me.
>
> I'm not entirely sure, but I think it might be connected to this
> bit of code in vl.c:
>
>   case QEMU_OPTION_acpitable:
>       opts = qemu_opts_parse_noisily(qemu_find_opts("acpi"),
>                                      optarg, true);
>
> This is the handling for the -acpitable option, but notice how "acpi"
> is mentioned as well, to perform some sort of lookup. I think this
> might be the reason why "acpi" gets included in the JSON, while
> "acpitable" doesn't.
>
> Another example I've found is "smp-opts", which seems to be used to
> implement the -smp option. Once again, in the JSON we find "smp-opts"
> instead of "smp".
>
> I think it would be worthwile to check with the QEMU developers and
> make sure that they're aware of this behavior. Is it intended? Is it
> documented anywhere? It certainly seems extremely confusing to me.

query-command-line-options has... issues.

First, it's generally[*] limited to options that use QemuOpts.

Second, it reports configuration group names, which are often, but not
always the same as the option name.  The exceptions you just have to
know.  Group name "acpi" vs. option name "acpitable" is one.

Third, information on option parameters can be incomplete, or missing
entirely.

Fourth, even when it's there, it's often insufficiently detailed.

These are design issues.  I believe the command cannot be fixed, only
replaced.

See my talk "QEMU interface introspection: From hacks to
solutions", KVM Forum 2015.
Video at https://www.youtube.com/watch?v=IEa8Ao8_B9o
Slides at http://www.linux-kvm.org/images/7/7a/02x05-Aspen-Markus_Armbruster-QEMU_interface_introspection.pdf

Questions?


[*] "Generally", because we hacked in a special case to keep "machine"
in its output when we weaned it off QemuOpts.  QEMU commit 40e07370f21.

Re: query-command-line-options (was: [PATCH 1/7] qemu: capabilities: Introduce QEMU_CAPS_MACHINE_ACPI)

[Peter Krempa]

On Tue, Mar 07, 2023 at 10:40:23 +0100, Markus Armbruster wrote:
> [Resent with cc: qemu-devel and adjusted subject, sorry for the noise]
> 
> abologna at redhat.com (Andrea Bolognani) writes:
> 
> > On Mon, Feb 27, 2023 at 06:25:23PM +0100, Peter Krempa wrote:
> >> On Mon, Feb 27, 2023 at 08:44:57 -0800, Andrea Bolognani wrote:

[...]

> > Another example I've found is "smp-opts", which seems to be used to
> > implement the -smp option. Once again, in the JSON we find "smp-opts"
> > instead of "smp".
> >
> > I think it would be worthwile to check with the QEMU developers and
> > make sure that they're aware of this behavior. Is it intended? Is it
> > documented anywhere? It certainly seems extremely confusing to me.
> 
> query-command-line-options has... issues.
> 
> First, it's generally[*] limited to options that use QemuOpts.
> 
> Second, it reports configuration group names, which are often, but not
> always the same as the option name.  The exceptions you just have to
> know.  Group name "acpi" vs. option name "acpitable" is one.

Ah! so that's where 'acpi' comes from.

> 
> Third, information on option parameters can be incomplete, or missing
> entirely.
> 
> Fourth, even when it's there, it's often insufficiently detailed.
> 
> These are design issues.  I believe the command cannot be fixed, only
> replaced.
> 
> See my talk "QEMU interface introspection: From hacks to
> solutions", KVM Forum 2015.
> Video at https://www.youtube.com/watch?v=IEa8Ao8_B9o
> Slides at http://www.linux-kvm.org/images/7/7a/02x05-Aspen-Markus_Armbruster-QEMU_interface_introspection.pdf
> 
> Questions?

In the end I've dropped the patch detecting the presence of the 'acpi'
option of -machine as queried via query-command-line-options, as we need
to know it per-machine type.  That is now reported by qemu in
query-machines, so we don't need to add more querying from
query-command-line options.

In fact I strive to eliminate it after your suggestions, but we can't
still detect the few outstanding flags from anywhere else.

List of currently outstanding queries using query-command-line-options:

    { "fsdev", "multidevs", QEMU_CAPS_FSDEV_MULTIDEVS },
    { "machine", "hpet", QEMU_CAPS_MACHINE_HPET },
    { "sandbox", NULL, QEMU_CAPS_SECCOMP_SANDBOX },
    { "spice", NULL, QEMU_CAPS_SPICE },
    { "spice", "gl", QEMU_CAPS_SPICE_GL },
    { "spice", "rendernode", QEMU_CAPS_SPICE_RENDERNODE },
    { "vnc", "power-control", QEMU_CAPS_VNC_POWER_CONTROL },

Re: query-command-line-options

[Markus Armbruster]

Stefan, one question regarding your commit 40e07370f21 inline.

Peter Krempa <pkrempa@redhat.com> writes:

[...]

> In fact I strive to eliminate it after your suggestions, but we can't
> still detect the few outstanding flags from anywhere else.
>
> List of currently outstanding queries using query-command-line-options:

Let me translate these into English questions:

>     { "fsdev", "multidevs", QEMU_CAPS_FSDEV_MULTIDEVS },

Does -fsdev have parameter "multidevs"?

It does since v4.2.

Aside: not documented in -help.

9p seems entirely absent from the QAPI schema.

>     { "machine", "hpet", QEMU_CAPS_MACHINE_HPET },

Does -machine have parameter "hpet"?

Aside: not documented in -help.

Since this is a special case in q-c-l-o (commit 40e07370f21 qemu-config:
restore "machine" in qmp_query_command_line_options()), the actual
question is whether any non-abstract machine class has a property
"hpet".

PC machines do since v5.2. (the HPET device is older, but it wasn't
configured with a machine property until v5.2).

Aside: "any non-abstract machine class"...  I think it used to be just
the current machine.  See the code taken out by commit d8fb7d0969d (vl:
switch -M parsing to keyval).  Accident in commit 40e07370f21?  Stefan?

There's CONFIG_HPET, but I can't see offhand how it plays together with
the machine property.

We could check for the machine property directly: check the properties
of the machine class in question with qom-list-properties, e.g.

    {"execute": "qom-list-properties",
     "arguments": {"typename": "pc-q35-8.1-machine"}}

To find all non-abstract machine classes, use

    {"execute": "qom-list-types", "arguments": {"implements": "machine"}}

>     { "sandbox", NULL, QEMU_CAPS_SECCOMP_SANDBOX },

Does option -sandbox exist?

It does since v1.2.  If CONFIG_SECCOMP is off, actually using it is a
fatal error.  Compiling out the option entirely would be more useful, I
guess.

Is this probe still useful?

>     { "spice", NULL, QEMU_CAPS_SPICE },

Does option -spice exist?

Since v7.0, it exists when CONFIG_SPICE is on.  I believe using it can
still fail when the module can't be loaded.

From v0.14 to v6.2 it exists even when CONFIG_SPICE is off, but actually
using it is a fatal error.

>     { "spice", "gl", QEMU_CAPS_SPICE_GL },

Does option -spice have parameter "gl"?

It does when CONFIG_OPENGL and CONFIG_OPENGL are both on (since v2.6).

query-display-options returns a value "gl" (since v2.12).  *Maybe*
that's a suitable witness.

>     { "spice", "rendernode", QEMU_CAPS_SPICE_RENDERNODE },

Does option -spice have parameter "rendernode"?

It does when CONFIG_OPENGL and CONFIG_OPENGL are both on (since v2.9).

Maybe query-display-options can serve for this one, too.

>     { "vnc", "power-control", QEMU_CAPS_VNC_POWER_CONTROL },

Does option -vnc have parameter "power-control"?

It does since v6.0.

Aside: -help does not document any of its parameters.

query-display-options is not implemented for VNC.  If we implement it,
it might become a suitable witness.

Re: query-command-line-options

[Ján Tomko]

[-- Attachment #1: Type: text/plain, Size: 965 bytes --]

On a Friday in 2023, Markus Armbruster wrote:
>>     { "sandbox", NULL, QEMU_CAPS_SECCOMP_SANDBOX },
>
>Does option -sandbox exist?
>
>It does since v1.2.  If CONFIG_SECCOMP is off, actually using it is a
>fatal error.  Compiling out the option entirely would be more useful, I
>guess.
>
>Is this probe still useful?

I believe so.

libvirt adds '-sandbox on' to all VMs it runs, unless the option is not
available.

Some users wanted to run libvirt with QEMUs without libseccomp,
which resulted in the following QEMU commit.

commit 0dd693ef1f15b6e9c4ba8b0118663e10338077cf
     sandbox: disable -sandbox if CONFIG_SECCOMP undefined

While using this option won't work if CONFIG_SECCOMP is off,
it should not show up in q-c-l-o so libvirt won't even try to use it.


If I'm reading
  commit 90835c2b8127406615785a9d4348ffdf3c813c8a
      seccomp: convert to meson
correctly, then the whole softmmu/qemu-seccomp.c file is only compiled
if seccomp was found.

Jano


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: query-command-line-options

[Markus Armbruster]

Ján Tomko <jtomko@redhat.com> writes:

> On a Friday in 2023, Markus Armbruster wrote:
>>>     { "sandbox", NULL, QEMU_CAPS_SECCOMP_SANDBOX },
>>
>>Does option -sandbox exist?
>>
>>It does since v1.2.  If CONFIG_SECCOMP is off, actually using it is a
>>fatal error.  Compiling out the option entirely would be more useful, I
>>guess.
>>
>>Is this probe still useful?
>
> I believe so.
>
> libvirt adds '-sandbox on' to all VMs it runs, unless the option is not
> available.
>
> Some users wanted to run libvirt with QEMUs without libseccomp,
> which resulted in the following QEMU commit.
>
> commit 0dd693ef1f15b6e9c4ba8b0118663e10338077cf
>     sandbox: disable -sandbox if CONFIG_SECCOMP undefined
>
> While using this option won't work if CONFIG_SECCOMP is off,
> it should not show up in q-c-l-o so libvirt won't even try to use it.

You're right: the option exists regardless of CONFIG_SECCOMP, but it
shows up in q-c-l-o only when CONFIG_SECCOMP is on.

> If I'm reading
>  commit 90835c2b8127406615785a9d4348ffdf3c813c8a
>      seccomp: convert to meson
> correctly, then the whole softmmu/qemu-seccomp.c file is only compiled
> if seccomp was found.
>
> Jano