| Message ID | 20201116131011.26607-1-r.bolshakov@yadro.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add HMP/QMP commands to query accelerator | expand |
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