Re: RFC: QMP configuration - allocating/setting qdev array properties?

[Damien Hedde]

Hi Mirela,

On 1/11/22 17:54, Mirela Grujic wrote:
> Hi,
>
>
> While working on a prototype and configuring a whole machine using QMP 
> we run into the following scenario.
>
>
> Some device models use array properties. The array is allocated when 
> len-<arrayname> property is set, then, individual elements of the array 
> can be set as any other property (see description above the 
> DEFINE_PROP_ARRAY definition in qdev-properties.h for more details). We 
> need to do both (allocate the array and set its elements) before the 
> device can be realized. Attempting to set len-<arrayname> and array 
> elements in a single device_add command does not work because the order 
> of setting properties is not guaranteed, i.e. we're likely attempting to 
> set an element of the array that's not yet allocated.

It happens because device options are stored in an optdict. When this 
optdict is traversed to set the qdev-properties, no specific order is used.

Better json format support would probably solve this issue in the 
long-term. But right now, we are stuck with the optdict in the middle 
which do not support advanced structure like lists or dictionaries.

We could solve this by being more "smart" in when setting the 
properties. I'm not sure we can be really smart here and detect which 
options is an array length but we could at least have some heuristic and 
for example: set first "len-xxx" properties so that array will be 
allocated before being filled.

> Allowing the device initialize and realize phases to be split would 
> solve this problem. For example, the device_add would be issued with 
> 'realized=false', we can set the len-<arrayname> in the same device_add 
> command or a following qom-set command, then we would use a sequence of 
> qom-set commands to set array elements, and at the end, we would realize 
> the device by issuing qom-set path=<device_id> property=realized 
> value=true. This is what we currently do in our prototype.

I think that is a bad idea. Because then the user would have access to a 
"not-realized" device (which is really a not-constructed object).
It could then do anything with the object (which might work or not 
might). And at the end, maybe realize will fail and that would leave 
qemu in a inconsistent state: the object will be used somewhere and at 
the same time it will be a state where it is not usable.

Thanks,
Damien