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

[Markus Armbruster <armbru@redhat.com>]

Eduardo Habkost <ehabkost@redhat.com> 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!