qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 02/12] accel: Introduce 'query-accels' QMP command


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH v4 02/12] accel: Introduce 'query-accels' QMP command
Date: Sun, 2 May 2021 00:24:08 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1

On 4/30/21 9:03 PM, Eric Blake wrote:
> On 4/15/21 11:32 AM, Philippe Mathieu-Daudé wrote:
>> Introduce the 'query-accels' QMP command which returns a list
>> of built-in accelerator names.
>>
>> - Accelerator is a QAPI enum of all existing accelerators,
>>
>> - AcceleratorInfo is a QAPI structure providing accelerator
>>   specific information. Currently the common structure base
>>   provides the name of the accelerator, while the specific
>>   part is empty, but each accelerator can expand it.
>>
>> - 'query-accels' QMP command returns a list of @AcceleratorInfo
>>
>> For example on a KVM-only build we get:
>>
>>     { "execute": "query-accels" }
>>     {
>>         "return": [
>>             {
>>                 "name": "qtest"
>>             },
>>             {
>>                 "name": "kvm"
>>             }
>>         ]
>>     }
>>
>> Note that we can't make the enum values or union branches conditional
>> because of target-specific poisoning of accelerator definitions.
>>
>> Reviewed-by: Eric Blake <eblake@redhat.com>
>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>> ---
>> Since v3: Simplify over-engineered AcceleratorInfo (Markus, kept Eric R-b)
>> Since v2: @since 6.0 -> 6.1, added note (Eric)
>> Since v1: 'type' -> 'name' in comments
> 
>> +++ b/qapi/machine.json
>> @@ -1274,3 +1274,50 @@
>>  ##
>>  { 'event': 'MEM_UNPLUG_ERROR',
>>    'data': { 'device': 'str', 'msg': 'str' } }
>> +
>> +##
>> +# @Accelerator:
>> +#
>> +# An enumeration of accelerator names.
>> +#
>> +# Since: 6.1
>> +##
>> +{ 'enum': 'Accelerator',
>> +  'data': [ 'qtest', 'tcg', 'kvm', 'hax', 'hvf', 'whpx', 'xen' ] }
> 
> There's no requirement for enums to be in any order, although if the
> list is likely to get larger over time, lexicographic order makes it
> easier to know where to insert new entries.  Up to you whether it is
> worth sorting, and your decision does not invalidate my R-b.

OK will do, thanks!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]