Re: [RFC PATCH v3 16/19] qmp: add query-cpu-props-info command

> On 5 Aug 2026, at 12:27 PM, Markus Armbruster <[email protected]> wrote:
> 
> !-------------------------------------------------------------------|
>  CAUTION: External Email
> 
> |-------------------------------------------------------------------!
> 
> Khushit Shah <[email protected]> writes:
> 
>>> On 4 Aug 2026, at 12:15 PM, Markus Armbruster <[email protected]> wrote:
>>> 
>>> !-------------------------------------------------------------------|
>>> CAUTION: External Email
>>> 
>>> |-------------------------------------------------------------------!
>>> 
>>> Khushit Shah <[email protected]> writes:
>>> 
>>>> Introduce the 'query-cpu-props-info' QMP command. For CPU model
>>>> properties it reports the type (boolean or number) and the set of values
>>>> supported under the active accelerator and host.
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> Signed-off-by: Khushit Shah <[email protected]>
>>> 
>>> 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.

Noted