Re: [Qemu-devel] qgraph

[Markus Armbruster <armbru@redhat.com>]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 10/06/19 18:12, Andreas Färber wrote:
>> Am 10.06.19 um 15:52 schrieb Paolo Bonzini:
>>> On 10/06/19 15:28, Andreas Färber wrote:
>>>> Am 10.06.19 um 14:03 schrieb Paolo Bonzini:
>>>>> Well, that was explained upthread---finding out what device can be
>>>>> plugged where.

Fair feature request.  It has come up before.

[...]
>>>> So if we want a new QMP operation, the most sense would probably make
>>>> where-can-I-attach-type(foo) returning a list of QOM paths, showing only
>>>> the first free slot per bus. That would allow a more efficient lookup
>>>> implementation inside QEMU than needing to check each slot[n] property
>>>> via qom-get after discovering it with qom-list.
>>>
>>> Note that what Natalia is seeking is an introspection mechanism to be
>>> used _before_ creating a virtual machine though.

This requires introspecting the machine to find its onboard devices,
then introspecting onboard devices to find relevant sockets.  Perhaps
even introspect the devices that could be plugged into available sockets
to find more sockets.

I'm afraid this founders right on the first step: we can't introspect
machines that way, can we?

Instead, we need to run with -M $machine_of_interest, then walk the QOM
tree to find the onboard devices.

>> QMP implied creating a virtual machine though.
>
> Yes, but you can start QEMU with -M none and just invoke QOM
> introspection commands.

Yes, this is how introspection (both QMP and QOM) is commonly used.
Just keep in mind one difference: QMP is static, QOM is dynamic.

QMP being static means it's defined at compile time.  So is the value of
query-qmp-schema.  Same QEMU build, same value.  This permits caching.

QOM being dynamic means to introspect an object's properties, you have
to create it.  Worse, an object's properties may (in theory) change at
any time.  *Properties*, not just property *values*.  In practice, I'd
expect properties to change only at realize time.

QOM introspection can only see the properties in a newly created object.
Even these could (in theory) depend on state, i.e.  the next time you
introspect, you could get a different result.  Even in the same process.

I never quite understood why QOM needs *that* much flexibility.  But it
is how it is.  The common way for a management application to deal with
it is to assume what introspection shows us is for all practical
purposes close enough to what we'll actually get.

[...]