Hi,

Management applications have no way to determine if certain accelerator
is available. That complicates discovery of non-KVM accelerators.

To address the issue, the series adds two commands:

  'query-accel' for QMP to be used by management apps, and

  'info accel' for HMP to replace 'info kvm' in future.

Thanks,
Roman

Roman Bolshakov (6):
  qapi: Add query-accel command
  qapi: Rename KvmInfo to AccelInfo
  qapi: Use qmp_query_accel() in qmp_query_kvm()
  softmmu: Remove kvm_available()
  hmp: Add 'info accel' command
  qapi: Deprecate 'query-kvm'

 hmp-commands-info.hx       | 13 +++++++++++++
 include/monitor/hmp.h      |  1 +
 include/sysemu/arch_init.h |  1 -
 monitor/hmp-cmds.c         | 36 ++++++++++++++++++++++++++++++++++--
 monitor/qmp-cmds.c         | 18 ++++++++++++++----
 qapi/machine.json          | 37 ++++++++++++++++++++++++++++++-------
 softmmu/arch_init.c        |  9 ---------
 7 files changed, 92 insertions(+), 23 deletions(-)

-- 
2.29.2

Ciao Roman,

On 11/16/20 2:10 PM, Roman Bolshakov wrote:
> Hi,
> 
> Management applications have no way to determine if certain accelerator
> is available. That complicates discovery of non-KVM accelerators.

are we thinking about how to make this future-proof when it comes to modularization efforts,
ie, when we get to fully modularized accelerator plugins?

Maybe too soon to consider, but still worth mentioning on my side I think.

Ciao,

Claudio

> 
> To address the issue, the series adds two commands:
> 
>   'query-accel' for QMP to be used by management apps, and
> 
>   'info accel' for HMP to replace 'info kvm' in future.
> 
> Thanks,
> Roman
> 
> Roman Bolshakov (6):
>   qapi: Add query-accel command
>   qapi: Rename KvmInfo to AccelInfo
>   qapi: Use qmp_query_accel() in qmp_query_kvm()
>   softmmu: Remove kvm_available()
>   hmp: Add 'info accel' command
>   qapi: Deprecate 'query-kvm'
> 
>  hmp-commands-info.hx       | 13 +++++++++++++
>  include/monitor/hmp.h      |  1 +
>  include/sysemu/arch_init.h |  1 -
>  monitor/hmp-cmds.c         | 36 ++++++++++++++++++++++++++++++++++--
>  monitor/qmp-cmds.c         | 18 ++++++++++++++----
>  qapi/machine.json          | 37 ++++++++++++++++++++++++++++++-------
>  softmmu/arch_init.c        |  9 ---------
>  7 files changed, 92 insertions(+), 23 deletions(-)
> 

On Thu, Nov 19, 2020 at 03:41:53PM +0100, Claudio Fontana wrote:
> On 11/16/20 2:10 PM, Roman Bolshakov wrote:
> > Management applications have no way to determine if certain accelerator
> > is available. That complicates discovery of non-KVM accelerators.
> 
> are we thinking about how to make this future-proof when it comes to
> modularization efforts, ie, when we get to fully modularized
> accelerator plugins?
> 
> Maybe too soon to consider, but still worth mentioning on my side I think.
> 

Hi Claudio,

I'd be happy to do it future-proof if you have something on the mind.
As far as I understand from the discussion, if we have /machine/accel
container, we can use QOM to query properties of the container including
accel name:
qom-get /machine/accel/type

Thanks,
Roman

On 11/19/20 4:46 PM, Roman Bolshakov wrote:
> On Thu, Nov 19, 2020 at 03:41:53PM +0100, Claudio Fontana wrote:
>> On 11/16/20 2:10 PM, Roman Bolshakov wrote:
>>> Management applications have no way to determine if certain accelerator
>>> is available. That complicates discovery of non-KVM accelerators.
>>
>> are we thinking about how to make this future-proof when it comes to
>> modularization efforts, ie, when we get to fully modularized
>> accelerator plugins?
>>
>> Maybe too soon to consider, but still worth mentioning on my side I think.
>>
> 
> Hi Claudio,
> 
> I'd be happy to do it future-proof if you have something on the mind.
> As far as I understand from the discussion, if we have /machine/accel
> container, we can use QOM to query properties of the container including
> accel name:
> qom-get /machine/accel/type
> 
> Thanks,
> Roman
> 

My understanding is very limited here, especially when it comes then to how libvirt f.e. uses this,

I wonder how to make sure that libvirt does not query the currently selected accelerator "too early",
ie before it has been finally selected (what in the other series I called the INIT_ACCEL_CPU time),

and how to query "available/supported" accelerators in a way that accounts for the fact that the plugin might not be loaded or available.

I guess this is a larger question about how libvirt detects modularized features in QEMU, when those features are (or are not) present only in an external binary plugin.

Ciao,

Claudio