Re: [Qemu-devel] [PATCH v13 6/6] qom: support arbitrary non-scalar properties with -object

[Paolo Bonzini <pbonzini@redhat.com>]

On 19/09/2016 14:29, Daniel P. Berrange wrote:
> On Mon, Sep 19, 2016 at 02:19:19PM +0200, Paolo Bonzini wrote:
>>
>>
>> On 19/09/2016 14:12, Daniel P. Berrange wrote:
>>> On Mon, Sep 19, 2016 at 12:58:30PM +0100, Daniel P. Berrange wrote:
>>>> The current -object command line syntax only allows for
>>>> creation of objects with scalar properties, or a list
>>>> with a fixed scalar element type. Objects which have
>>>> properties that are represented as structs in the QAPI
>>>> schema cannot be created using -object.
>>>>
>>>> This is a design limitation of the way the OptsVisitor
>>>> is written. It simply iterates over the QemuOpts values
>>>> as a flat list. The support for lists is enabled by
>>>> allowing the same key to be repeated in the opts string.
>>>>
>>>> It is not practical to extend the OptsVisitor to support
>>>> more complex data structures while also maintaining
>>>> the existing list handling behaviour that is relied upon
>>>> by other areas of QEMU.
>>>>
>>>> Fortunately there is no existing object that implements
>>>> the UserCreatable interface that relies on the list
>>>> handling behaviour, so it is possible to swap out the
>>>> OptsVisitor for a different visitor implementation, so
>>>> -object supports non-scalar properties, thus leaving
>>>> other users of OptsVisitor unaffected.
>>>
>>> Urgh, I've just discovered that this is not in fact true.
>>>
>>> The 'memory-backend' object type uses uint16List which
>>> has the hacky list syntax
>>>
>>>   -object memory-backend-ram,\
>>>           id=ram-node2,size=24578621440,policy=bind,\
>>>           host-nodes=1-2,host-nodes=5,host-nodes=7,
>>>
>>> So I'll need to figure out a way to preserve this syntax...
>>
>> Is there a usecase for qdict_crumple without the following
>> de-stringification pass?  If not, qdict_crumple could use a
>> StringInputVisitor on the values directly.
> 
> I'm not sure I understand how that would help and in any case, the
> string-input-visitor itself is incapable of dealing with compound
> properties.

> It too could/should be ultimately replaced by the
> qobject-input-visitor combined with a pre-processing step to
> turn the input string into a qdict.
> 
> The problem I'm facing with the above scenario though occurs
> before we get anywhere near the visitors, or the crumple step.
> 
> When qemu_opts_to_qdict() turns QemuOpts into QDict, it looses
> repeated options.

Ouch, I thought the problem was only with "1-2", not with the repeated
host-nodes.  Wow, that does really work?!?

What might work is if you convert the repeated options to
"host-nodes=1-2,5,7".  Then StringInputVisitor is able to parse that
(but OptsVisitor isn't).

I'm not sure if there are other uses of repeated options.  Probably not
based on a limited inspection of callers of qemu_opt_foreach.

Paolo

> What I need to do is make qemu_opts_to_qdict more intelligent
> so that if it sees repeated strings, it inserts them into the
> qdict using list index style. eg, the QemuOpts -> QDict
> conversion should have at minimum given us
> 
>     type=memory-backend-ram
>     id=ram-node2
>     size=24578621440
>     policy=bind
>     host-nodes.0=1-2
>     host-nodes.1=5
>     host-nodes.2=7
> 
> although even then there's some magic in the range value seen there. I'm
> unclear on whether we should try to deal with the range "1-2" in the
> qemu_opts_to_qdict() method, the qdict_crumple() method or the qobject
> input visitor code for parsing ints.
> 
> Regards,
> Daniel
>