[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Making QEMU easier for management tools and applications

From: Markus Armbruster
Subject: Re: Making QEMU easier for management tools and applications
Date: Wed, 15 Jan 2020 10:20:58 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Christophe de Dinechin <address@hidden> writes:

> I started cutting some stuff out.
>> On 14 Jan 2020, at 14:04, Markus Armbruster <address@hidden> wrote:
>> Prior art:
>>    Presentation
>>    KVM Forum 2017: Towards a More Expressive and Introspectable QEMU
>>    Command Line
>>    https://www.youtube.com/watch?v=gtpOLQgnwug
>>    https://www.linux-kvm.org/images/f/f2/Armbru-qapi-cmdline_1.pdf
>>    RFC patches
>>    https://lists.nongnu.org/archive/html/qemu-devel/2017-10/msg00209.html
>>    Message-Id: <address@hidden>
>>    https://repo.or.cz/qemu/armbru.git/shortlog/refs/heads/qapi-cmdline
> Very useful, thanks.
>>> Compatibility is much harder, which is not the least because the
>>> existing command line options are bad (primarily: using inconsistent
>>> syntax).
>> Semantics are just as problematic.
> Yes, but often you can leverage something (e.g. JSON, XML, etc)
> We could decide that the new QAPI language is a custom implementation
> of Python ;-) Or more seriously, we could have some part of the JSON
> schema that are “escapes” to C code that we put in some generated file.
> I used {{ }} below for this escape, in which case the semantics would be
> that of C plus some specific macros we insert in it.
> { 'option': '--add-fd',
>  'data': { 'fd': 'int', 'set': 'int', '*opaque': 'str' },
>  'help': [
> "-add-fd fd=fd,set=set[,opaque=opaque]",
> "                Add 'fd' to fd 'set'”] 
>  ‘validate’ : {{
>     error_if(QOPT.fd < 0, “fd option cannot be negative”);
>     error_if(QOPT.fd <= STDERR_FILENO, “fd cannot be a standard I/O stream”);
>  }},
>  ‘exec’ : {{
>     if (do_add_fd(QOPT.fd, QOPT.fset, QOPT.opaque) < 0) {
>         exit(1);
>     }
>  }},
> I’m not necessarily saying this is a good idea, mind you.

Precedence: the value of 'if' is also a C snippet.

>> You mean the qemu-options.hx.  qemu-options.def is generated from it.
> Oh, I had missed that, thanks.
>>>> or build configuration (there is a hint of the connection between
>>>> the two in the option ‘if’ member in the .json files).
>> I'm not sure what exactly you have in mind for build configuration.
> I meant what you pointed out wrt. options, that this “language” needs to
> know about the qemu configuration. There is ‘if’ today, you pointed
> out arch-specific for options. But the configuration itself is yet
> another “language” with its own semantics… which JSON knows
> nothing about.

QAPI 'if' is a pragmatic design balancing simplicty with expressiveness.

It's part of the QAPI language except for the actual conditions.  The
QAPI generator blindly wraps whatever it generates for the thing
carrying an 'if': 'COND' in #if COND ... #endif /* COND */.  In other
words, we express "what is conditional" in the QAPI language, but resort
to the C language for expressing the actual conditionals.

* Supports arbitrary #if.
* QAPI language impact is light: just another (string-valued) property
  of definitions and members.
* Generated code is the same regardless of QEMU configuration.

* Generating anything but C is problematic.  Currently that's just
  documentation.  Having C conditionals there isn't exactly great, but

>>>> In other words, the language I have in mind would be something
>>>> that I could auto-generate from, say, the current qapi-schema.json
>>>> and the qemu-options.def. Maybe in the end, that would be simply
>>>> by having qemu-options.def being used to build qemu-options.json,
>>>> and then add the relevant entries in qemu-options.json. Maybe
>>>> there is a better way.
>>> I would rather say that .def should go away and its content should
>>> be converted to a JSON schema that becomes the new source format rather
>>> than an intermediate generated file. There is nothing in .def files that
>>> couldn't be represented in the schema.
>> Yes.
> Agreed too. The meta-schema would need to be extended.
>>> To a certain degree, QAPI does just that, by supporting different data
>>> types for options. If necessary, I'm sure the type system could be
>>> extended, but it's not clear to me to which degree we actually need
>>> this.
>> QAPI is much more expressive than qemu-options.hx.  All the latter can
>> do is "has option argument" and "option is arch-specific".  QAPI lets
>> you specify an option argument's structure, and supports compile-time
>> conditionals.  It can't do things like "must specify either argument A
>> or B", or "numeric argument C must not exceed argument D", or "multiple
>> options combine vs. last one wins".  Mostly because "it’s already
>> complicated enough as is".
> Understood.
>>> We could. But is it actually worth inventing a new programming language?
>>> I think this is something that should be done in C code even in the
>>> future. I think what we're looking for is a way to describe interfaces,
>>> not implementations.
>> Sane sugar can be described declaratively as macro expansion.
>> Less than sane sugar takes code.
>> Desugaring in code promotes (accidental) abandonment of sanity.
>> That said, we have to keep things simple to succeed.  Declarative
>> desugaring seems beyond our reach.
> Well, “keeping things simple” is a complicated thing.


>>> Even just for adding more sophisticated constraints, like in the example
>>> above that maxmem >= size, it's questionable whether doing this in the
>>> schema provides enough value for actually implementing it there.
>> Yes.
> If we do it, yes. If we delegate to an existing language (I showed C above),
> maybe it adds clarity without too much of an additional cost.


>>>>> I think the only thing in this list that can't obviously be covered
>>>>> easily by QAPI is QOM. Or rather, it's covered by passing through
>>>>> key=value lists without describing their structure
>>>> That’s close enough to me. (In my mind, that part was already “done”
>>>> by QAPI, even if in the convoluted way you describe)
>>> That's not really close enough. If you are happy with this level of
>>> abstraction, you can define any command line option to be either a flag
>>> or take a string as its argument and be done. This is obviously not very
>>> helpful because it says nothing about the structure of that string.
>> Similar to all QMP commands taking a single 'any' argument.
> Hmmm, I guess I have not understood what you meant by
> "QOM could not be covered easily by QAPI" then.

I think Kevin's point is that QAPI can't fully describe QOM.

Let's talk specifics.  Here's how QAPI defines blockdev-add:

    { 'command': 'blockdev-add', 'data': 'BlockdevOptions', 'boxed': true }
    { 'union': 'BlockdevOptions',
      'base': { 'driver': 'BlockdevDriver',
                '*detect-zeroes': 'BlockdevDetectZeroesOptions' },
      'discriminator': 'driver',
      'data': {
          'blkdebug':   'BlockdevOptionsBlkdebug',
          'vxhs':       'BlockdevOptionsVxHS'
      } }
    { 'enum': 'BlockdevDriver',
      'data': [ 'blkdebug', 'blklogwrites', [...], 'vxhs' ] }

QAPI specifies the available blockdev object types and their properties,
with types.

Compare object-add:

    { 'command': 'object-add',
      'data': {'qom-type': 'str', 'id': 'str', '*props': 'any'} }

QAPI specifies neither the available QOM object types, nor their
properties.  Consequently, QAPI/QMP introspection tells you nothing
about them.  You need to use QOM introspection instead.  qom-list-types
shows what QOM object types are available, and qom-list-properties shows
an object type's properties.  Except for dynamic ones created only after
object creation).  With undocumented type name strings instead of types.

> We don’t want the QAPI to let arbitrary fields of a QOM object
> be modified, do we?

We already do: QMP command qom-set.  If it breaks your guest, you get to
keep the pieces.

> As for the “public” aspects of a QOM object, that is static if it
> comes from QAPI, so why couldn’t we define it there?

QAPI specifies a certain kind of data types.

QOM "specifies" data types as an imperative program for creating them.
Maximally flexible, and fundamentally at odds with static analysis.
I've hated this since day one.

There's no hard reason why QOM could not specify static aspects
declaratively.  It just doesn't, and changing it now would be a
monumental task.

The imperative program mostly creates identical data types every time.
In other words, the data types are static.  Two problems.  One,
converting such a program to an equivalent declaration takes manual
labor.  Two, there are exceptions, and identifying them is more manual

>>> the same way, QAPI can't say anything about the structure of a QOM
>>> object, and I think that's a problem.
>>>>> - which, as far as I
>>>>> understand, is mainly because QOM properties aren't necessarily static,
>>>>> so we can't provide a statically defined interface for them. Probably
>>>>> solvable in QEMU, but not without a major effort.
>>>> Or maybe extend the language so that it’s internal semantics
>>>> knows about this aspect of QOM?
>>> My point is that for example you can't generate a C struct (which is
>>> statically defined) from something that has a dynamic structure. The
>>> best you could do is fall back to key=value even in the C source, both
>>> key and value being strings. But then you still have to parse these
>>> strings manually, so it doesn't actually help much compared to a state
>>> without C bindings.
> I really don’t understand that point. To me, all these operations
> seem relatively simple to generate.

Yes, if the QAPI fairy gives us a declarative specification equivalent
to the existing imperative one, then replacing the hand-written
imperative code by code generated from the declarative specification
would be relatively simple.

> I think that what confuses me is when you write “something that has a
> dynamic structure”. I understand that as referring to the structure
> defined in the schema. But the schema itself is static. So you can
> generate static code from it, and it’s already done today.

QAPI data types are static.

QOM types are not.  They're effectively almost static in practice.

> Another hypothesis on my side is that we don’t want, ever, to
> have the API provide for example the option to create its own
> arbitrary QOM classes, or to tag arbitrary properties to an object,
> where by “arbitrary” I mean not explicitly mentioned somewhere in
> something like the schema.
> So I suspect you are talking about something else.

Kevin's talking about the imperative code creating different QOM
properties depending on how and in what context it is run.

QOM is perfectly capable of supporting a QMP command to add arbitrary
QOM properties to an object at run time, or even add arbitrary QOM
types, but as you wrote we don't want that.

>> QOM and QAPI sabotage each other.  Ironic, considering they were dreamed
>> up by the same guy :)
>> QAPI is compile-time static by design.
>> QOM is run-time dynamic by design.  Some support for static definitions
>> has been grafted on since.
>> We use QAPI type system escapes for QOM.  Defeats QAPI introspection and
>> doc generation.  We provide separate QOM introspection instead, which is
>> clumsier and less expressive.  QOM documentation doesn't exist.
> But back to the original discussion about management tools,
> do we let upper layers tag their own arbitrary stuff in QOM objects?

We don't want management applications to add QOM properties for their
own purposes.

>>> Maybe what could be done is covering at least the static properties and
>>> then having key=value for the dynamic part (which should be the
>>> exception).
>> To make this worthwhile, we'd have to replace dynamic QOM properties by
>> static ones when possible.  Monumental task.
> I’m sure you are right, but it’s hard for me to evaluate, given how
> many ways there are to access an object. Naively, grepping for
> set_prop and for new_with_prop does not give me that many hits.

Look for object_property_add*().  Some 450 hits.

See also object_class_property_add(), grafted on in

commit 16bf7f522a2ff68993f80631ed86254c71eaf5d4
Author: Daniel P. Berrange <address@hidden>
Date:   Tue Oct 13 13:37:46 2015 +0100

    qom: Allow properties to be registered against classes
    When there are many instances of a given class, registering
    properties against the instance is wasteful of resources. The
    majority of objects have a statically defined list of possible
    properties, so most of the properties are easily registerable
    against the class. Only those properties which are conditionally
    registered at runtime need be recorded against the klass.
    Registering properties against classes also makes it possible
    to provide static introspection of QOM - currently introspection
    is only possible after creating an instance of a class, which
    severely limits its usefulness.
    This impl only supports simple scalar properties. It does not
    attempt to allow child object / link object properties against
    the class. There are ways to support those too, but it would
    make this patch more complicated, so it is left as an exercise
    for the future.
    There is no equivalent to object_property_del() provided, since
    classes must be immutable once they are defined.
    Signed-off-by: Daniel P. Berrange <address@hidden>
    Signed-off-by: Andreas Färber <address@hidden>

>>>>>> - Relations, e.g. how we represent “contains”, “derives from”, “needs”,
>>>>>> “one of”, “one or several”, “attaches to”…
>>>>>> - States, e.g. how do we represent the machine configuration,
>>>>>> or the desired new disk setting
>>>>>> - Verbs, e.g. how we represent “add”, “connect”, “remove”, “find”,
>>>>>> “start”, “notify”, etc. and how we describe the kind of input they need.
>>>>>> - Possibly more subtle things like support for transactions, 
>>>>>> commit/rollback,
>>>>>> i.e. “I want to add connect a virtual nic to some host vf, but if 
>>>>>> anything
>>>>>> along the way fails, I’d like all the cleanup to happen automatically)
>>>>> This sounds like a different approach from our current QAPI command set
>>>> Well, except for purposefully trying to use a different wording to avoid
>>>> the risk of getting your mind stuck in one of the particular existing
>>>> meta-languages in QEMU, the approach is not very different.
>>> I didn't necessarily mean relations/state/verbs, which obviously exist,
>>> but the examples that seemed to express things in a deliberately
>>> different way from what we have today.
>>>> - Transactions do not exist today that I know of, although we see
>>>> signs of them in discussions about the fact that this options destroys
>>>> that back end but that option does not.
>>> We have a 'transaction' QMP command, but they are not an integral part
>>> of the language. Considering the trouble to implement transactional
>>> commands, I suppose we don't even want it to be a fundamental part of
>>> the language.
>>>>> Does it actually provide more functionality, though?
>>>> It’s not intended to provide more, but to require less to do the same 
>>>> thing.
>>> Though we always need to keep in mind that if requiring less for future
>>> additions requires a huge effort now, the investment may pay off only in
>>> a very distant future (if the abstraction we build even survives until
>>> then).
>> Worse is better.
>> http://dreamsongs.com/RiseOfWorseIsBetter.html
> You know that I positively hate this ;-)

It's been a tough lesson for me, too.

> Well, I guess we can expand the schema. #ILoveJSON.

Basing the QAPI language on JSON was a poor choice.  Not sure that's
fixable at a reasonable cost.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]