Re: [RFC PATCH v2 23/29] target/arm/qmp: add query-arm-cpu-props-info

[Markus Armbruster <armbru@redhat.com>]

I apologize for taking so long to reply.

Khushit Shah <khushit.shah@nutanix.com> writes:

>> On 19 Jun 2026, at 2:55 PM, Markus Armbruster <armbru@redhat.com> wrote:
>> 
>> !-------------------------------------------------------------------|
>>  CAUTION: External Email
>> 
>> |-------------------------------------------------------------------!
>> 
>> Khushit Shah <khushit.shah@nutanix.com> writes:
>> 
>>> Introduce 'query-arm-cpu-props-info' QMP command. This command returns
>>> information about ARM CPU model properties, including their name, type,
>>> supported values on the given host, and composite parent if any.
>>> 
>>> This provides management layer necessary information to determine
>>> migration compatibility off a VM on different host.
>
> Note: s/off/of.
>
>>> 
>>> Signed-off-by: Khushit Shah <khushit.shah@nutanix.com>
>>> ---
>>> qapi/misc-arm.json              | 41 ++++++++++++++++
>>> stubs/qmp-arm-gic.c             |  6 +++
>>> target/arm/arm-cpu-props-stub.c | 13 +++++
>>> target/arm/arm-cpu-props.c      | 85 +++++++++++++++++++++++++++++++++
>>> target/arm/arm-cpu-props.h      |  5 ++
>>> target/arm/arm-qmp-cmds.c       | 44 +++++++++++++++++
>>> target/arm/cpu-idregs.c         | 71 +++++++++++++++++++++++++++
>>> target/arm/cpu-idregs.h         |  8 ++++
>>> 8 files changed, 273 insertions(+)
>>> 
>>> diff --git a/qapi/misc-arm.json b/qapi/misc-arm.json
>>> index 4dc66d00e5..1a3fb140c4 100644
>>> --- a/qapi/misc-arm.json
>>> +++ b/qapi/misc-arm.json
>>> @@ -46,6 +46,47 @@
>>> ##
>>> { 'command': 'query-gic-capabilities', 'returns': ['GICCapability'] }
>>> 
>>> +##
>>> +# @CpuPropInfo:
>> 
>> CpuPropertyInfo for consistency with type names such as ObjectPropertyInfo.
>
> Acked. 
>
>>> +#
>>> +# Information about a specific ARM CPU model property.
>>> +#
>>> +# @name: the name of the property
>>> +#
>>> +# @type: the type of the property, any of ('string', 'boolean',
>>> +#     'number').
>>> +#
>>> +# @supported-values: the set of values the host hardware supports
>>> +#     for the property, a list of strings.
>> 
>> I figure the set of values depends on the host, i.e. it isn't known at
>> compile time.  Correct?
>> 
>
> Yes, correct.
>
>> Are the possible property names known at compile time?
>
> Yes, property names are known at compile time.

Why can't we use a struct then?

    { 'struct': ...
      'data': {
          'PROP1': 'TYPE1',
          'PROP2': 'TYPE2',
          ... } }

>> List of strings is fine when the values are strings.  When they're not,
>> the interface requires its users to parse strings, which is something we
>> try hard to avoid in QAPI/QMP.
>
> Okay, then I think we can do this with flat union discriminated with 
> “type” (changing it to enum) :
>    boolean: [‘bool’]
>    string: [’str’]
>    number: ['NumRange’] where NumRange: {‘min’: uint64, ‘max’: uint64}
>
> Range form to handle numeric properties with no restrictions.
>
> Does this look reasonable to you?

Yes, this is a reasonable way to do dynamic typing in QAPI.

I still need to understand why you you dynamic types here.

[...]