Re: [Qemu-devel] [Qemu-ppc] [QEMU-PPC] [PATCH V3 0/6] target/ppc: Rework spapr_caps

[Andrea Bolognani <abologna@redhat.com>]

On Mon, 2018-01-15 at 17:32 +1100, Suraj Jitindar Singh wrote:
> The following patch series adds 3 new tristate capabilities and their
> associated handling.
> 
> A new H-Call is implemented which a guest will use to query the
> requirement for and availability of workarounds for certain cpu
> behaviours.
> 
> Applies on top of David's tree: ppc-for-2.12
> 
> The first patch from the previous revision has already been merged:
> hw/ppc/spapr_caps: Rework spapr_caps to use uint8 internal representation
> 
> The main changes to V3 are:
> - Split up the addition of the tristate caps into 5 patches
>   - 1/6 query the caps from the hypervisor and parse the new return format
>   - 2/6 add support for the new caps
>   - 3-5/6 add each of the three new caps
> - Patch 6/6 Unchanged

Correct me if I'm wrong, but it seems to me like there's no way
to figure out through QMP whether these new machine options can be
used for a given QEMU binary.

If so, that's very unfortunate because it means that libvirt has
only two options: 1) just use them if the user requests the
corresponding feature, which will lead to older QEMU binaries
simply refusing to start; or 2) perform a version number check,
which will not be accurate if downstream backports are involved.

Would this information be added to the MachineInfo struct, so that
query-machines reports it? Or would a new QMP command be more
appropriate for the task?

Alternatively, if there's any witness we can use instead of an
explicit capability, let me know. But I still think we should
think about a better long-term solution, especially because this
seems to be happening quite frequently lately: see the hpt-resizing
and max-cpu-compat machine properties, which are just as opaque
from an introspection point of view.

Sorry for not bringing this up earlier.

-- 
Andrea Bolognani / Red Hat / Virtualization