Re: [RFC PATCH v3 16/19] qmp: add query-cpu-props-info command
Markus Armbruster <[email protected]> Wed, 05 Aug 2026 08:57:20 +0200
| Newsgroups | org.nongnu.qemu-arm,dev.linux.lists.kvmarm,org.nongnu.qemu-devel |
|---|---|
| Message-ID | <[email protected]> |
Khushit Shah <[email protected]> writes: >> On 4 Aug 2026, at 12:15=E2=80=AFPM, Markus Armbruster <[email protected]= > wrote: >>=20 >> !-------------------------------------------------------------------| >> CAUTION: External Email >>=20 >> |-------------------------------------------------------------------! >>=20 >> Khushit Shah <[email protected]> writes: >>=20 >>> Introduce the 'query-cpu-props-info' QMP command. For CPU model >>> properties it reports the type (boolean or number) and the set of value= s >>> supported under the active accelerator and host. >>>=20 >>> For numbers the supported values are expressed as a list of inclusive >>> {min, max} ranges; for booleans as the list of allowed true/false >>> values. >>>=20 >>> The command and its return types (CpuPropertyType, CpuPropertyInfo and >>> friends) are defined in qapi/machine.json rather than an Arm-specific >>> schema, since the concept applies to other targets (e.g. x86, riscv) >>> too. Target that do not implement it return an error. >>>=20 >>> The Arm/KVM implementation spins up a scratch "host" vCPU object, >>> walks its QOM properties: SYSREG_ ID-register fields become 'number' >>> properties whose ranges come from arm_field_get_supported_values(), >>> and the advertised feature toggles become 'boolean' properties. >>>=20 >>> Signed-off-by: Khushit Shah <[email protected]> >>=20 >> This explains what the command does and how it's implemented. It's >> silent on the most important aspect: why do we want the command? What >> is its intended purpose? > > Will add something like: > > This helps the management stack to discover which values are supported > for a given CPU property. This is especially important for non-boolean > properties, where knowing that the host has value 'x' does not inherently > reveal the full range of valid values supported on the host. Better. Perhaps throw in an example if you can come up with a simple one.