On Mon, Sep 28, 2026 at 10:24:39PM +0800, Yonggang Luo wrote:
> On Mon, Sep 28, 2026 at 6:14 PM Daniel P. Berrangé <[email protected]>
> wrote:
> >
> > I don't think that we need to report machines though.
> > We already have 'query-machines' which gives much broader
> > information on the machines. "MachineInfo" needs to
> > gain
> >
> > "targets": ["SysEmuTarget"]
> >
> > to list which target(s) a machine can be used with.
> >
>
> This is my final design for the query-target / query-targets / query-machines,
> for consistency and testability.
>
> Per review: reuse `QemuTargetInfo` for both target commands, drop the
> per-target machine list, and let
> `MachineInfo` say which target(s) each machine runs on.
> `QemuTargetInfo` stays small; `query-target` and `query-targets` return a
> derived struct that adds the target's device and accel Kconfig state.
>
> ## QemuTargetInfo
>
> ```
> { 'struct': 'QemuTargetInfo',
> 'data': { 'arch': 'SysEmuTarget' } } # since 1.2
> ```
> ## QemuTargetDetails: QemuTargetInfo plus kconfig
>
> ```
> { 'struct': 'QemuTargetDetails',
> 'base': 'QemuTargetInfo',
> 'data': { 'kconfig': 'any' } }
> ```
>
> `kconfig` maps every device and accel `CONFIG_*` symbol to whether it
> is enabled for that target.
KConfig is an internal implementation detail that should not be exposed
to management apps as we don't want KConfig to become an ABI we must
preserve. QAPI introspection provides feature based information to
the user. eg instead of querying for "CONFIG_SEV", qom-list-types can
be queried to look for the 'sev-guest' class.
With regards,
Daniel
--
|: https://berrange.com ~~ https://hachyderm.io/@berrange :|
|: https://libvirt.org ~~ https://entangle-photo.org :|
|: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
