Re: [Qemu-devel] [PATCHv2 3/3] qmp: add architecture specific cpu data for query-cpus-fast

[Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>]

On 14.02.2018 16:27, Cornelia Huck wrote:
> On Wed, 14 Feb 2018 09:15:23 -0600
> Eric Blake <eblake@redhat.com> wrote:
> 
>> On 02/14/2018 04:15 AM, Cornelia Huck wrote:
>>> On Tue, 13 Feb 2018 18:18:48 +0100
>>> Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> wrote:
>>>   
>>
>>>> A suggestion was made on the mailing list to enhance the QAPI
>>>> code generation to support two layers of unions. This would
>>>> allow to specify the common fields once and avoid the duplication
>>>> in the leaf unions.
>>>>
>>>> On the other hand, the slow query-cpus should be deprecated
>>>> along with the slow CpuInfo type and eventually be removed.
>>>> Assuming that new architectures will not be added at high
>>>> rates, we could live with the duplication for the time being.  
>>>
>>> What would be a realistic timeframe for deprecation/removal of
>>> query-cpus, considering the libvirt usage? Are we aware of other users?  
>>
>> Well, if we want to start the clock ticking, this series also needs to 
>> touch qemu-doc.texi to start the deprecation clock, then we go at least 
>> two more releases with support for both old and new commands.
>>
> 
> I'd like to know first what libvirt plans to do -- no sense in starting
> deprecation if we're still stuck with it for a while.
> 
FWIW, I'm currently preparing libvirt patches to use query-cpus-fast if
available. I wouldn't see why it would take more than one libvirt
release to get them in.

The question might rather be, which combinations of qemu and libvirt are
considered useful. E.g., I didn't upgrade libvirt in a while on my test
system but am using bleeding edge QEMU. But that doesn't necessarily
resemble a valid setup.

-- 
Regards,
 Viktor Mihajlovski