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

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 2420 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]