Re: [Qemu-devel] qgraph

["Andreas Färber" <afaerber@suse.de>]

Am 10.06.19 um 14:03 schrieb Paolo Bonzini:
> On 10/06/19 13:57, Andreas Färber wrote:
>> Your question doesn't make sense grammatically or conceptually. As Paolo
>> explained below, QOM is a pure object model, with object types/classes
>> and properties. Buses are just object instances attached as properties
>> and don't necessarily even need their own type of bus object (e.g, CPU).
>> An answer you don't like doesn't change by asking it to other people...
>> The information is all there, you just need to interpret it correctly.
>>
>> There is no technical discussion (no concrete proposal of yours) to
>> comment on here, and kindly refer to last week's change of maintainers.
>>
>> You would be better off just explaining what you really want to achieve.
> 
> Well, that was explained upthread---finding out what device can be
> plugged where.
> 
> Let's see what is in QOM right now:
> 
> $ qemu-kvm -qmp unix:foo.sock,server,nowait -device virtio-scsi-pci,id=vs
> $ ./qmp/qom-list -s ~/foo.sock /machine/peripheral/vs|less
> 
> There is a "virtio-bus" here, and iside it there is a scsi-bus.
> 
> $ ./qmp/qom-list -s ~/foo.sock /machine/peripheral/vs/virtio-bus/child[0]/
> vs.0/
> 
> I guess you could add to virtio-scsi-pci a class property for the bus,
> and then make "vs.0" an alias to that class property.  This would allow
> you find buses by enumerating the class properties.

That kind of goes against the spirit of QOM though and ignores simpler
mechanisms of hot-plugging, as mentioned.

The theoretical generic way would be to discover that any random object
beneath /machine has a null property of a link<> type that inherits from
device and is compatible with the device type to be plugged.

In practice we decided against Anthony's idea of adding tons of empty
slot properties for e.g. PCI buses (the number space is too large). We
did add QOM support for wildcard "foo[*]" array properties though. A
null slot[42] property of a certain link<> type then means a device can
be plugged there, and the property's setter then needs to take care of
hot-plugging and un-plugging.
This was unfortunately obscured by the legacy qdev model where we
magically add new child[0] properties (pointing to
/machine/peripheral(-anon) sub-nodes) to its bus parent during device
instantiation IIRC.

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.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)