Re: [Qemu-devel] qgraph

Re: [Qemu-devel] qgraph

[Natalia Fursova]

ping

 

 

Best regards, 

Natalia

 

From: Наталья Фурсова [mailto:Natalia.Fursova@ispras.ru] 
Sent: Wednesday, May 29, 2019 2:57 PM
To: 'qemu-devel@nongnu.org'; 'pbonzini@redhat.com'; Паша
(Pavel.Dovgaluk@ispras.ru)
Subject: qgraph

 

Hello, Paolo!

 

We develop GUI for Qemu and want to implement graphical interface for
configuring the device tree. To do this we need to detect list of the
devices supported by any specific platform.

Then we use this tree for command line generation.

 

Existing qmp commands don't supply enough information to build the tree.
They miss bus and interface data.

 

There is something called 'qgraph' in Qemu. It looks similar to data
structures in our GUI tool.

 

Tell me please, do you have a plan on improving this interface? We found the
following hardcoded lines in the tests:

qos_node_consumes("megasas", "pci-bus", &opts);

qos_node_produces("megasas", "pci-device");

 

And we wanted to extend QMP to query this kind of information.

 

 

Best regards, 

Natalia

 

Re: [Qemu-devel] qgraph

[Paolo Bonzini]

On 04/06/19 10:37, Natalia Fursova wrote:
> Hello, Paolo!
> 
> We develop GUI for Qemu and want to implement graphical interface for
> configuring the device tree. To do this we need to detect list of the
> devices supported by any specific platform.
> 
> Then we use this tree for command line generation.
> 
> Existing qmp commands don't supply enough information to build the tree.
> They miss bus and interface data.

Hi!

Bus data is implicit in the parent class provided by QMP.  For example,
pci-device is the superclass of PCI devices, scsi-device is the
superclass of SCSI devices, etc.

qgraph is indeed similar, but it is only used by test cases, not by QEMU
itself.  The difference is that qgraph links together _drivers_ for the
devices, and so it is limited to those devices that have tests.  For
some ideas behind qgraph, see
https://wiki.qemu.org/Features/qtest_driver_framework.

Paolo

> 
>  
> 
> There is something called 'qgraph' in Qemu. It looks similar to data
> structures in our GUI tool.
> 
>  
> 
> Tell me please, do you have a plan on improving this interface? We found the
> following hardcoded lines in the tests:
> 
> qos_node_consumes("megasas", "pci-bus", &opts);
> 
> qos_node_produces("megasas", "pci-device");
> 
>  
> 
> And we wanted to extend QMP to query this kind of information.
> 
>  
> 
>  
> 
> Best regards, 
> 
> Natalia
> 
>  
> 

Re: [Qemu-devel] qgraph

[Natalia Fursova]

Hello, Paolo!

Thank you for your answer. I would like to clarify something about the qmp
commands.
For example, consider SCSI controller "lsi53c895a". For getting information
we use two commands: "device-list-properties" and "qom-list-properties".
Output consists of many properties, but there is no information about
provided buses by this device. Is there a qmp command which provides this
information?


Best regards,
Natalia

-----Original Message-----
From: Paolo Bonzini [mailto:pbonzini@redhat.com] 
Sent: Tuesday, June 04, 2019 6:06 PM
To: Natalia Fursova; qemu-devel@nongnu.org; Паша
Subject: Re: [Qemu-devel] qgraph

On 04/06/19 10:37, Natalia Fursova wrote:
> Hello, Paolo!
> 
> We develop GUI for Qemu and want to implement graphical interface for
> configuring the device tree. To do this we need to detect list of the
> devices supported by any specific platform.
> 
> Then we use this tree for command line generation.
> 
> Existing qmp commands don't supply enough information to build the tree.
> They miss bus and interface data.

Hi!

Bus data is implicit in the parent class provided by QMP.  For example,
pci-device is the superclass of PCI devices, scsi-device is the
superclass of SCSI devices, etc.

qgraph is indeed similar, but it is only used by test cases, not by QEMU
itself.  The difference is that qgraph links together _drivers_ for the
devices, and so it is limited to those devices that have tests.  For
some ideas behind qgraph, see
https://wiki.qemu.org/Features/qtest_driver_framework.

Paolo

> 
>  
> 
> There is something called 'qgraph' in Qemu. It looks similar to data
> structures in our GUI tool.
> 
>  
> 
> Tell me please, do you have a plan on improving this interface? We found
the
> following hardcoded lines in the tests:
> 
> qos_node_consumes("megasas", "pci-bus", &opts);
> 
> qos_node_produces("megasas", "pci-device");
> 
>  
> 
> And we wanted to extend QMP to query this kind of information.
> 
>  
> 
>  
> 
> Best regards, 
> 
> Natalia
> 
>  
> 

Re: [Qemu-devel] qgraph

[Paolo Bonzini]

On 05/06/19 14:34, Natalia Fursova wrote:
> 
> Thank you for your answer. I would like to clarify something about the qmp
> commands.
> For example, consider SCSI controller "lsi53c895a". For getting information
> we use two commands: "device-list-properties" and "qom-list-properties".
> Output consists of many properties, but there is no information about
> provided buses by this device. Is there a qmp command which provides this
> information?

Unfortunately there is no information in QMP about buses that are
provided.   qom-list-types gives the buses that are requested.

Paolo

Re: [Qemu-devel] qgraph

[Natalia Fursova]

I see.
We need this opportunity and want to implement it. Will it ok for QOM
conception?



Best regards,
Natalia

-----Original Message-----
From: Paolo Bonzini [mailto:pbonzini@redhat.com] 
Sent: Wednesday, June 05, 2019 4:07 PM
To: Natalia Fursova; qemu-devel@nongnu.org; 'Паша'
Subject: Re: [Qemu-devel] qgraph

On 05/06/19 14:34, Natalia Fursova wrote:
> 
> Thank you for your answer. I would like to clarify something about the qmp
> commands.
> For example, consider SCSI controller "lsi53c895a". For getting
information
> we use two commands: "device-list-properties" and "qom-list-properties".
> Output consists of many properties, but there is no information about
> provided buses by this device. Is there a qmp command which provides this
> information?

Unfortunately there is no information in QMP about buses that are
provided.   qom-list-types gives the buses that are requested.

Paolo

Re: [Qemu-devel] qgraph

[Natalia Fursova]

Hi there!
Read please our correspondence and answer on last question (Will it ok for
QOM conception?)
Also forwarding to QOM and QMP maintainers. Can you make comments on this
discussion?


Best regards,
Natalia

-----Original Message-----
From: Natalia Fursova [mailto:Natalia.Fursova@ispras.ru] 
Sent: Wednesday, June 05, 2019 5:23 PM
To: 'Paolo Bonzini'; 'qemu-devel@nongnu.org'; 'Паша'
Subject: RE: [Qemu-devel] qgraph

I see.
We need this opportunity and want to implement it. Will it ok for QOM
conception?



Best regards,
Natalia

-----Original Message-----
From: Paolo Bonzini [mailto:pbonzini@redhat.com] 
Sent: Wednesday, June 05, 2019 4:07 PM
To: Natalia Fursova; qemu-devel@nongnu.org; 'Паша'
Subject: Re: [Qemu-devel] qgraph

On 05/06/19 14:34, Natalia Fursova wrote:
> 
> Thank you for your answer. I would like to clarify something about the qmp
> commands.
> For example, consider SCSI controller "lsi53c895a". For getting
information
> we use two commands: "device-list-properties" and "qom-list-properties".
> Output consists of many properties, but there is no information about
> provided buses by this device. Is there a qmp command which provides this
> information?

Unfortunately there is no information in QMP about buses that are
provided.   qom-list-types gives the buses that are requested.

Paolo

Re: [Qemu-devel] qgraph

[Andreas Färber]

Hi Natalia,

Am 10.06.19 um 11:53 schrieb Natalia Fursova:
> Hi there!
> Read please our correspondence and answer on last question (Will it ok for
> QOM conception?)
> Also forwarding to QOM and QMP maintainers. Can you make comments on this
> discussion?

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.

Regards,
Andreas

> -----Original Message-----
> From: Natalia Fursova [mailto:Natalia.Fursova@ispras.ru] 
> Sent: Wednesday, June 05, 2019 5:23 PM
> To: 'Paolo Bonzini'; 'qemu-devel@nongnu.org'; 'Паша'
> Subject: RE: [Qemu-devel] qgraph
> 
> I see.
> We need this opportunity and want to implement it. Will it ok for QOM
> conception?
> 
> 
> 
> Best regards,
> Natalia
> 
> -----Original Message-----
> From: Paolo Bonzini [mailto:pbonzini@redhat.com] 
> Sent: Wednesday, June 05, 2019 4:07 PM
> To: Natalia Fursova; qemu-devel@nongnu.org; 'Паша'
> Subject: Re: [Qemu-devel] qgraph
> 
> On 05/06/19 14:34, Natalia Fursova wrote:
>>
>> Thank you for your answer. I would like to clarify something about the qmp
>> commands.
>> For example, consider SCSI controller "lsi53c895a". For getting
> information
>> we use two commands: "device-list-properties" and "qom-list-properties".
>> Output consists of many properties, but there is no information about
>> provided buses by this device. Is there a qmp command which provides this
>> information?
> 
> Unfortunately there is no information in QMP about buses that are
> provided.   qom-list-types gives the buses that are requested.
> 
> Paolo
> 


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

Re: [Qemu-devel] qgraph

[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.

Paolo

Re: [Qemu-devel] qgraph

[Andreas Färber]

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)

Re: [Qemu-devel] qgraph

[Paolo Bonzini]

On 10/06/19 15:28, Andreas Färber wrote:
> 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.

Paolo

Re: [Qemu-devel] qgraph

[Andreas Färber]

Am 10.06.19 um 15:52 schrieb Paolo Bonzini:
> On 10/06/19 15:28, Andreas Färber wrote:
>> 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.

QMP implied creating a virtual machine though.

This then goes back to the long-discussed topic of not doing recursive
realized=true when starting halted with -s but deferring that to the
cont operation. I doubt that's been implemented in the meantime?

Cheers,
Andreas

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

Re: [Qemu-devel] qgraph

[Paolo Bonzini]

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:
>>> 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.
> 
> QMP implied creating a virtual machine though.

Yes, but you can start QEMU with -M none and just invoke QOM
introspection commands.

> This then goes back to the long-discussed topic of not doing recursive
> realized=true when starting halted with -s but deferring that to the
> cont operation. I doubt that's been implemented in the meantime?

Nope.

Paolo

Re: [Qemu-devel] qgraph

[Markus Armbruster]

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.

[...]

Re: [Qemu-devel] qgraph

[Paolo Bonzini]

On 11/06/19 10:56, Markus Armbruster wrote:
> 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.

Right, and we should move more towards class-based properties so that
the dynamic nature of QOM is only used for the bare minimum needed (e.g.
memory regions).

Paolo

Re: [Qemu-devel] qgraph

[Markus Armbruster]

Paolo Bonzini <pbonzini@redhat.com> writes:

> On 11/06/19 10:56, Markus Armbruster wrote:
>> 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.
>
> Right, and we should move more towards class-based properties so that
> the dynamic nature of QOM is only used for the bare minimum needed (e.g.
> memory regions).

What are we doing to make new code conform to that?

What are we doing to update existing code?

Re: [Qemu-devel] qgraph

[Paolo Bonzini]

On 11/06/19 15:39, Markus Armbruster wrote:
>> Right, and we should move more towards class-based properties so that
>> the dynamic nature of QOM is only used for the bare minimum needed (e.g.
>> memory regions).
> What are we doing to make new code conform to that?
> 
> What are we doing to update existing code?

Almost nothing and completely nothing. :(

Paolo

Re: [Qemu-devel] qgraph

[Natalia Fursova]

Hi there again!
Thank you for your answers, I have new question.
 
I want to identify PCI devices (e.g. network cards) and observed one strange thing. I use qmp command "qom-list-type" and build tree from it output. Some items don't have parent and don't give information about themselves. E. g. "e1000-base". It has three children and it belongs to PCI devices, but I can't know it, cuz command "qom-list-properties" returns empty message.

There is no information about "e1000-base" in "qom-list-type" output. It is referenced only as a parent for network cards.
Is it ok? Maybe is there other way for get information about all PCI devices?



Best regards,
Natalia


-----Original Message-----
From: Paolo Bonzini [mailto:pbonzini@redhat.com] 
Sent: Tuesday, June 11, 2019 4:45 PM
To: Markus Armbruster
Cc: Natalia Fursova; Andreas Färber; 'Паша'; qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qgraph

On 11/06/19 15:39, Markus Armbruster wrote:
>> Right, and we should move more towards class-based properties so that
>> the dynamic nature of QOM is only used for the bare minimum needed (e.g.
>> memory regions).
> What are we doing to make new code conform to that?
> 
> What are we doing to update existing code?

Almost nothing and completely nothing. :(

Paolo

Re: [Qemu-devel] qgraph

[Markus Armbruster]

"Natalia Fursova" <Natalia.Fursova@ispras.ru> writes:

> Hi there again!
> Thank you for your answers, I have new question.
>  
> I want to identify PCI devices (e.g. network cards) and observed one
> strange thing. I use qmp command "qom-list-type" and build tree from
> it output. Some items don't have parent and don't give information
> about themselves. E. g. "e1000-base". It has three children and it
> belongs to PCI devices, but I can't know it, cuz command
> "qom-list-properties" returns empty message.
>
> There is no information about "e1000-base" in "qom-list-type"
> output. It is referenced only as a parent for network cards.  Is it
> ok? Maybe is there other way for get information about all PCI
> devices?

qom-list-types only returns concrete types by default.  Try passing
"abstract": true.

Re: [Qemu-devel] qgraph

[Natalia Fursova]

Thank you!

С уважением, 
Наталья


-----Original Message-----
From: Markus Armbruster [mailto:armbru@redhat.com] 
Sent: Tuesday, July 02, 2019 6:26 PM
To: Natalia Fursova
Cc: 'Paolo Bonzini'; 'Andreas Färber'; 'Паша'; qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qgraph

"Natalia Fursova" <Natalia.Fursova@ispras.ru> writes:

> Hi there again!
> Thank you for your answers, I have new question.
>  
> I want to identify PCI devices (e.g. network cards) and observed one
> strange thing. I use qmp command "qom-list-type" and build tree from
> it output. Some items don't have parent and don't give information
> about themselves. E. g. "e1000-base". It has three children and it
> belongs to PCI devices, but I can't know it, cuz command
> "qom-list-properties" returns empty message.
>
> There is no information about "e1000-base" in "qom-list-type"
> output. It is referenced only as a parent for network cards.  Is it
> ok? Maybe is there other way for get information about all PCI
> devices?

qom-list-types only returns concrete types by default.  Try passing
"abstract": true.

Re: [Qemu-devel] qgraph

[Peter Maydell]

On Tue, 2 Jul 2019 at 12:51, Natalia Fursova <Natalia.Fursova@ispras.ru> wrote:
>
> Hi there again!
> Thank you for your answers, I have new question.
>
> I want to identify PCI devices (e.g. network cards) and observed one strange thing. I use qmp command "qom-list-type" and build tree from it output. Some items don't have parent and don't give information about themselves. E. g. "e1000-base". It has three children and it belongs to PCI devices, but I can't know it, cuz command "qom-list-properties" returns empty message.
>
> There is no information about "e1000-base" in "qom-list-type" output. It is referenced only as a parent for network cards.
> Is it ok? Maybe is there other way for get information about all PCI devices?

e1000-base is an abstract base class for the e1000, e1000-82544pc and
e1000-82545em devices, which are the ones users can actually create and
use. It's an internal implementation detail, so you don't need to care
about it.

thanks
-- PMM

Re: [Qemu-devel] qgraph

[Andreas Färber]

Am 11.06.19 um 12:31 schrieb Paolo Bonzini:
> On 11/06/19 10:56, Markus Armbruster wrote:
>> 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.
> 
> Right, and we should move more towards class-based properties so that
> the dynamic nature of QOM is only used for the bare minimum needed (e.g.
> memory regions).

I believe it was Paolo who once reminded me that all child<> properties
are dynamic. And link<> properties for bus devices are also dynamic. I
don't see a good way around that.

Regards,
Andreas

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