On Tue, Jan 16, 2018 at 02:47:13PM +0100, Andrea Bolognani wrote: > 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.
Uh, I don't think so. These are machine options like any other (just
constructed a bit differently). So they'll appear in qemu -machine
pseries,? and I believe that info can also be retrieved with QMP.
> 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.
>
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: PGP signature
