Re: [libvirt] [Qemu-devel] [PATCH 7/9] qmp: Add runnability information to query-cpu-definitions

Eduardo Habkost <ehabkost(a)redhat.com&gt; writes: > On Mon, May 30, 2016 at 11:33:38AM +0200, Markus Armbruster wrote: [...] >> The new members encode an answer to the question whether a certain CPU >> usable with the current machine an accelerator, and if no, why. >> The possible answers are: >> >> (1) Don't know. >> (2) Yes. >> (3) No, but we can't say why. >> (4) No, and here's a list of reasons. >> >> The two "dunno" answers (1) and (3) exist so we don't have to boil the >> CPU ocean now. >> >> Without them, the natural solution is a single member, where (4) is >> encoded as nonempty list, and (2) could be encoded as empty list or >> absent. >> >> Now let me try to fit in (1) and (3). >> >> The obvious way to do (1) is absent. So let's use empty list for (2). >> >> That leaves (3). I think the simplest solution that could possibly work >> is to treat it as a special "dunno" reason: encode it just like (4), but >> with a special "dunno" list element. I'd use the empty string. >> >> Could even be used if we need to distinguish >> >> (4a) No, and here's the *complete* list of reasons. >> (4b) No, and here's a possibly incomplete list of reasons. >> >> For (4b), include the "dunno" element with the others. >> >> Unlike the proposed solution, this one doesn't leave interface crud >> behind if we succeed in getting rid of (1) and (3): >> >> * When (1) goes away, the single member becomes mandatory. >> >> * When (3) goes away, the special "dunno" list element no longer occurs. > > I like your suggestion. > > I suggest "type" as the "dunno" element. It would keep the > existing "QOM property name" semantics, and it would just mean > "sorry, the only advice we can currently give you is to choose a > different CPU type". It even matches the previous documentation I > sent describing the meaning of read-only property names. > > Rewriting the docs again: > > # Virtual CPU definition. > # > # @name: the name of the CPU definition > -# @runnable: #optional Whether the CPU model us usable with the > -# current machine and accelerator. Omitted if we don't > -# know the answer. (since 2.7) > -# @unavailable-features: #optional List of attributes that prevent > +# @unavailable-features: #optional List of properties that prevent > # the CPU model from running in the current > -# host. Present only if @runnable is false. > -# (since 2.7) > +# host. (since 2.7) > # > # @unavailable-features is a list of QOM property names that > # represent CPU model attributes that prevent the CPU from running. > -# If the QOM property is read-only, that means the CPU model can > -# never run in the current host. If the property is read-write, it > +# If the QOM property is read-only, that means there's no known > +# way to make the CPU model run in the current host. > +# If the property is read-write, it > # means that it MAY be possible to run the CPU model in the current > # host if that property is changed. Management software can use it > # as hints to suggest or choose an alternative for the user, or > # just to generate meaningful error messages explaining why the CPU > # model can't be used. Should we spell out the special case "type"?

> +# If @unavailable-features is an empty list, the CPU model is > +# runnable using the current host and machine-type. > +# If @unavailable-features is not present, runnability > +# information for the CPU model is not available. > # > # Since: 1.2.0 > ## I'm happy with this interface. Thanks!