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