Re: [Qemu-devel] [RFC][PATCH 0/21] QEMU Object Model

[Paolo Bonzini <pbonzini@redhat.com>]

On 07/25/2011 03:44 AM, Anthony Liguori wrote:
> Hi,
>
> This series is the rough beginnings of the QEMU Object Model.  This is basically
> qdev generalized on steroids.
>
> This series includes the core infrastructure, a strawman Device type, and
> the beginnings of the conversion of CharDriverState.  This is in a rougher
> state than I would like it to be but I wanted to get the concepts on the list
> as soon as possible.
>
> My plan is to drop the Device parts from future versions of the series and just
> focus on backends to start with.

I am not sure of how the Device and Char/Block/NetworkDriver bits relate 
to each other.  It seems to me that they are two very different families 
of objects, and we should treat them differently.

For host devices (Char/Block/Network) we have a relatively simple 
interface but we need a richer way to create and destroy the objects at 
runtime.  We have it already for block and network, we don't for char, 
but it is done ad hoc for each hierarchy.  We do not have a deep 
hierarchy, in fact there is no hierarchy at all (only one abstract class 
per subsystem).

Honestly, it is not too bad.  It may not be the cleanest code, but is it 
worth the kind of ramifications that your patch has?  Of course, the 
answer could be "yes" if the same model can be applied to devices. 
Devices do have the same introspection needs more or less, and I like 
your ideas there.  However, the requirements are very different in terms 
of composition.

Also because there is no hierarchy, composition in host devices can be 
done very easily.  A decorator for char/block devices, such as a "tee" 
device, can treat the wrapped object(s) the same independent of the 
actual class.  A simple vtable works very well.  GObject would also do 
well, unifying the introspection at the cost of significantly more 
boilerplate.

     (Of course, we could rewrite QEMU in Vala).

For *guest* devices, however, this is not the case.  The PCI host needs 
to know that the device on the other end is a PCI device.  Even the 
simplest bus, for example I2C, has methods defined on its children.

So, the most important point, it seems to me, is to support composition 
effectively.  There need not be any hierarchy at all---not even the 
two-level hierarchy we have now, everything can inherit from 
DeviceState---but the combination between devices must be:

1) in a flexible manner, so that it can express complex topologies (as 
long as "plugs" and "sockets" have the same shape of course);

2) in an easily introspectable manner, so that migration and QMP and so 
on work very well in the presence of said topologies;

3) in a precise manner, so that the two devices being connected can 
interact effectively;


The current qdev fails completely at (1).  (2) is very limited if you 
consider qdev only; qdev+VMState is at least decent, though nowhere near 
the potential of QOM.

However, qdev gets (3) right by making interaction between the parent 
and the child go through a bus object that knows the details of both. 
In particular, bus objects and their vtable structures are very 
effective in qdev because they provide flexibility and avoid impedence 
mismatch, with a very limited amount of boilerplate.

By contrast, the plug/socket model in QOM achieves (1) and (2), but in 
my opinion it fails at (3).  The model for example is not effective in 
specifying the properties of the socket, which are roughly are the bus 
properties and the fields added by DeviceState abstract subclasses in 
the current qdev; it is not clear where they would live in QOM.  Perhaps 
in the parent device or in an intermediate object between the parent and 
the child; if the latter, it looks like a lot of pointer chasing and a 
conversion nightmare.


Based on my earlier conversations with Peter, I thought a bit on how to 
do more incremental changes to qdev in order to overcome the 
inflexibility.  Here is a rough overview of the steps:


1) make properties more flexible.  In particular, we *absolutely* need 
array properties, either static or dynamic.  The current special casing 
of GPIO pins is required exactly because we do not have arrays of 
properties.

Also, since arrays occur a lot in the device state, array properties 
would also be required to be able to introspect on run-time properties 
(which are now part of VMState only).  However, I am not going to 
consider run-time introspection much more.  It is "a simple matter of 
programming" if your general introspection design is done right.


2) add more kinds of first-class (user specifiable) properties.  GPIO 
pins, for example, which are already part of qdev but cannot be 
specified by the user on the command line.  Possibly memory regions too. 
  Anything that can be used to configure a device (with respect to the 
main bus or to its parent) should be a property.


3) at this point, you can get rid of the specialties of SysBus devices. 
  IRQs are an array of GPIO properties, same for memory regions.  SysBus 
devices can use a naked DeviceState structure.

At this point, many embedded devices could be entirely described in 
terms of configuration files, except for legacy options (-serial kind) 
and for the few devices that attach directly to the CPU.  This without 
the need to define artificial buses that do not exist in real hardware.


4) add support for compound properties.  A compound properties is such 
that you define a property named (coincidence...) "bus" and you get 
automatically "bus.parent", "bus.addr", "bus.romfile", "bus.rombar" etc.


5) convert buses to compound properties.  Rather than inheriting from 
PCIDevice, a PCI device would inherit straight from DeviceState and 
include a PCIDevice struct that defines the backlink from a device to 
its parent.  Note that since we're using C, this is not a big change 
from what we're doing now!  (Inheritance by containment is a special 
case of containment.)  And it allows to define very flexibly a device 
that would have to sit on two or more buses in the current qdev model. 
More importantly, it keeps the effectiveness of the qbus ops model, 
while removing the constraint of a tree topology.


It is only when this is done, that we should reconsider introspection 
and see if it is useful/sensible to unify the host and guest device 
object models.

Because the host models we have now, with all the defects they may have, 
*work*.  The guest models hardly work for anything but PCs, and even 
then only for the subset of devices which are interesting to 
hot-plug/unplug.  And so it is from them that we should start designing.

Thoughts?

Paolo