xref: /openbmc/qemu/docs/devel/qom.rst (revision 784155cdcb02ffaae44afecab93861070e7d652d)
1 .. _qom:
2 
3 ===========================
4 The QEMU Object Model (QOM)
5 ===========================
6 
7 .. highlight:: c
8 
9 The QEMU Object Model provides a framework for registering user creatable
10 types and instantiating objects from those types.  QOM provides the following
11 features:
12 
13 - System for dynamically registering types
14 - Support for single-inheritance of types
15 - Multiple inheritance of stateless interfaces
16 - Mapping internal members to publicly exposed properties
17 
18 The root object class is TYPE_OBJECT which provides for the basic
19 object methods.
20 
21 The QOM tree
22 ============
23 
24 The QOM tree is a composition tree which represents all of the objects
25 that make up a QEMU "machine". You can view this tree by running
26 ``info qom-tree`` in the :ref:`QEMU monitor`. It will contain both
27 objects created by the machine itself as well those created due to
28 user configuration.
29 
30 Creating a QOM class
31 ====================
32 
33 A simple minimal device implementation may look something like below:
34 
35 .. code-block:: c
36    :caption: Creating a minimal type
37 
38    #include "qdev.h"
39 
40    #define TYPE_MY_DEVICE "my-device"
41 
42    // No new virtual functions: we can reuse the typedef for the
43    // superclass.
44    typedef DeviceClass MyDeviceClass;
45    typedef struct MyDevice
46    {
47        DeviceState parent_obj;
48 
49        int reg0, reg1, reg2;
50    } MyDevice;
51 
52    static const TypeInfo my_device_info = {
53        .name = TYPE_MY_DEVICE,
54        .parent = TYPE_DEVICE,
55        .instance_size = sizeof(MyDevice),
56    };
57 
58    static void my_device_register_types(void)
59    {
60        type_register_static(&my_device_info);
61    }
62 
63    type_init(my_device_register_types)
64 
65 In the above example, we create a simple type that is described by #TypeInfo.
66 #TypeInfo describes information about the type including what it inherits
67 from, the instance and class size, and constructor/destructor hooks.
68 
69 The TYPE_DEVICE class is the parent class for all modern devices
70 implemented in QEMU and adds some specific methods to handle QEMU
71 device model. This includes managing the lifetime of devices from
72 creation through to when they become visible to the guest and
73 eventually unrealized.
74 
75 Alternatively several static types could be registered using helper macro
76 DEFINE_TYPES()
77 
78 .. code-block:: c
79 
80    static const TypeInfo device_types_info[] = {
81        {
82            .name = TYPE_MY_DEVICE_A,
83            .parent = TYPE_DEVICE,
84            .instance_size = sizeof(MyDeviceA),
85        },
86        {
87            .name = TYPE_MY_DEVICE_B,
88            .parent = TYPE_DEVICE,
89            .instance_size = sizeof(MyDeviceB),
90        },
91    };
92 
93    DEFINE_TYPES(device_types_info)
94 
95 Every type has an #ObjectClass associated with it.  #ObjectClass derivatives
96 are instantiated dynamically but there is only ever one instance for any
97 given type.  The #ObjectClass typically holds a table of function pointers
98 for the virtual methods implemented by this type.
99 
100 Using object_new(), a new #Object derivative will be instantiated.  You can
101 cast an #Object to a subclass (or base-class) type using
102 object_dynamic_cast().  You typically want to define macro wrappers around
103 OBJECT_CHECK() and OBJECT_CLASS_CHECK() to make it easier to convert to a
104 specific type:
105 
106 .. code-block:: c
107    :caption: Typecasting macros
108 
109    #define MY_DEVICE_GET_CLASS(obj) \
110       OBJECT_GET_CLASS(MyDeviceClass, obj, TYPE_MY_DEVICE)
111    #define MY_DEVICE_CLASS(klass) \
112       OBJECT_CLASS_CHECK(MyDeviceClass, klass, TYPE_MY_DEVICE)
113    #define MY_DEVICE(obj) \
114       OBJECT_CHECK(MyDevice, obj, TYPE_MY_DEVICE)
115 
116 In case the ObjectClass implementation can be built as module a
117 module_obj() line must be added to make sure qemu loads the module
118 when the object is needed.
119 
120 .. code-block:: c
121 
122    module_obj(TYPE_MY_DEVICE);
123 
124 Class Initialization
125 --------------------
126 
127 Before an object is initialized, the class for the object must be
128 initialized.  There is only one class object for all instance objects
129 that is created lazily.
130 
131 Classes are initialized by first initializing any parent classes (if
132 necessary).  After the parent class object has initialized, it will be
133 copied into the current class object and any additional storage in the
134 class object is zero filled.
135 
136 The effect of this is that classes automatically inherit any virtual
137 function pointers that the parent class has already initialized.  All
138 other fields will be zero filled.
139 
140 Once all of the parent classes have been initialized, #TypeInfo::class_init
141 is called to let the class being instantiated provide default initialize for
142 its virtual functions.  Here is how the above example might be modified
143 to introduce an overridden virtual function:
144 
145 .. code-block:: c
146    :caption: Overriding a virtual function
147 
148    #include "qdev.h"
149 
150    void my_device_class_init(ObjectClass *klass, void *class_data)
151    {
152        DeviceClass *dc = DEVICE_CLASS(klass);
153        dc->reset = my_device_reset;
154    }
155 
156    static const TypeInfo my_device_info = {
157        .name = TYPE_MY_DEVICE,
158        .parent = TYPE_DEVICE,
159        .instance_size = sizeof(MyDevice),
160        .class_init = my_device_class_init,
161    };
162 
163 Introducing new virtual methods requires a class to define its own
164 struct and to add a .class_size member to the #TypeInfo.  Each method
165 will also have a wrapper function to call it easily:
166 
167 .. code-block:: c
168    :caption: Defining an abstract class
169 
170    #include "qdev.h"
171 
172    typedef struct MyDeviceClass
173    {
174        DeviceClass parent_class;
175 
176        void (*frobnicate) (MyDevice *obj);
177    } MyDeviceClass;
178 
179    static const TypeInfo my_device_info = {
180        .name = TYPE_MY_DEVICE,
181        .parent = TYPE_DEVICE,
182        .instance_size = sizeof(MyDevice),
183        .abstract = true, // or set a default in my_device_class_init
184        .class_size = sizeof(MyDeviceClass),
185    };
186 
187    void my_device_frobnicate(MyDevice *obj)
188    {
189        MyDeviceClass *klass = MY_DEVICE_GET_CLASS(obj);
190 
191        klass->frobnicate(obj);
192    }
193 
194 Interfaces
195 ----------
196 
197 Interfaces allow a limited form of multiple inheritance.  Instances are
198 similar to normal types except for the fact that are only defined by
199 their classes and never carry any state.  As a consequence, a pointer to
200 an interface instance should always be of incomplete type in order to be
201 sure it cannot be dereferenced.  That is, you should define the
202 'typedef struct SomethingIf SomethingIf' so that you can pass around
203 ``SomethingIf *si`` arguments, but not define a ``struct SomethingIf { ... }``.
204 The only things you can validly do with a ``SomethingIf *`` are to pass it as
205 an argument to a method on its corresponding SomethingIfClass, or to
206 dynamically cast it to an object that implements the interface.
207 
208 Methods
209 -------
210 
211 A *method* is a function within the namespace scope of
212 a class. It usually operates on the object instance by passing it as a
213 strongly-typed first argument.
214 If it does not operate on an object instance, it is dubbed
215 *class method*.
216 
217 Methods cannot be overloaded. That is, the #ObjectClass and method name
218 uniquely identity the function to be called; the signature does not vary
219 except for trailing varargs.
220 
221 Methods are always *virtual*. Overriding a method in
222 #TypeInfo.class_init of a subclass leads to any user of the class obtained
223 via OBJECT_GET_CLASS() accessing the overridden function.
224 The original function is not automatically invoked. It is the responsibility
225 of the overriding class to determine whether and when to invoke the method
226 being overridden.
227 
228 To invoke the method being overridden, the preferred solution is to store
229 the original value in the overriding class before overriding the method.
230 This corresponds to ``{super,base}.method(...)`` in Java and C#
231 respectively; this frees the overriding class from hardcoding its parent
232 class, which someone might choose to change at some point.
233 
234 .. code-block:: c
235    :caption: Overriding a virtual method
236 
237    typedef struct MyState MyState;
238 
239    typedef void (*MyDoSomething)(MyState *obj);
240 
241    typedef struct MyClass {
242        ObjectClass parent_class;
243 
244        MyDoSomething do_something;
245    } MyClass;
246 
247    static void my_do_something(MyState *obj)
248    {
249        // do something
250    }
251 
252    static void my_class_init(ObjectClass *oc, void *data)
253    {
254        MyClass *mc = MY_CLASS(oc);
255 
256        mc->do_something = my_do_something;
257    }
258 
259    static const TypeInfo my_type_info = {
260        .name = TYPE_MY,
261        .parent = TYPE_OBJECT,
262        .instance_size = sizeof(MyState),
263        .class_size = sizeof(MyClass),
264        .class_init = my_class_init,
265    };
266 
267    typedef struct DerivedClass {
268        MyClass parent_class;
269 
270        MyDoSomething parent_do_something;
271    } DerivedClass;
272 
273    static void derived_do_something(MyState *obj)
274    {
275        DerivedClass *dc = DERIVED_GET_CLASS(obj);
276 
277        // do something here
278        dc->parent_do_something(obj);
279        // do something else here
280    }
281 
282    static void derived_class_init(ObjectClass *oc, void *data)
283    {
284        MyClass *mc = MY_CLASS(oc);
285        DerivedClass *dc = DERIVED_CLASS(oc);
286 
287        dc->parent_do_something = mc->do_something;
288        mc->do_something = derived_do_something;
289    }
290 
291    static const TypeInfo derived_type_info = {
292        .name = TYPE_DERIVED,
293        .parent = TYPE_MY,
294        .class_size = sizeof(DerivedClass),
295        .class_init = derived_class_init,
296    };
297 
298 Alternatively, object_class_by_name() can be used to obtain the class and
299 its non-overridden methods for a specific type. This would correspond to
300 ``MyClass::method(...)`` in C++.
301 
302 One example of such methods is ``DeviceClass.reset``. More examples
303 can be found at :ref:`device-life-cycle`.
304 
305 Standard type declaration and definition macros
306 ===============================================
307 
308 A lot of the code outlined above follows a standard pattern and naming
309 convention. To reduce the amount of boilerplate code that needs to be
310 written for a new type there are two sets of macros to generate the
311 common parts in a standard format.
312 
313 A type is declared using the OBJECT_DECLARE macro family. In types
314 which do not require any virtual functions in the class, the
315 OBJECT_DECLARE_SIMPLE_TYPE macro is suitable, and is commonly placed
316 in the header file:
317 
318 .. code-block:: c
319    :caption: Declaring a simple type
320 
321    OBJECT_DECLARE_SIMPLE_TYPE(MyDevice, MY_DEVICE)
322 
323 This is equivalent to the following:
324 
325 .. code-block:: c
326    :caption: Expansion from declaring a simple type
327 
328    typedef struct MyDevice MyDevice;
329    typedef struct MyDeviceClass MyDeviceClass;
330 
331    G_DEFINE_AUTOPTR_CLEANUP_FUNC(MyDeviceClass, object_unref)
332 
333    #define MY_DEVICE_GET_CLASS(void *obj) \
334            OBJECT_GET_CLASS(MyDeviceClass, obj, TYPE_MY_DEVICE)
335    #define MY_DEVICE_CLASS(void *klass) \
336            OBJECT_CLASS_CHECK(MyDeviceClass, klass, TYPE_MY_DEVICE)
337    #define MY_DEVICE(void *obj)
338            OBJECT_CHECK(MyDevice, obj, TYPE_MY_DEVICE)
339 
340    struct MyDeviceClass {
341        DeviceClass parent_class;
342    };
343 
344 The 'struct MyDevice' needs to be declared separately.
345 If the type requires virtual functions to be declared in the class
346 struct, then the alternative OBJECT_DECLARE_TYPE() macro can be
347 used. This does the same as OBJECT_DECLARE_SIMPLE_TYPE(), but without
348 the 'struct MyDeviceClass' definition.
349 
350 To implement the type, the OBJECT_DEFINE macro family is available.
351 In the simple case the OBJECT_DEFINE_TYPE macro is suitable:
352 
353 .. code-block:: c
354    :caption: Defining a simple type
355 
356    OBJECT_DEFINE_TYPE(MyDevice, my_device, MY_DEVICE, DEVICE)
357 
358 This is equivalent to the following:
359 
360 .. code-block:: c
361    :caption: Expansion from defining a simple type
362 
363    static void my_device_finalize(Object *obj);
364    static void my_device_class_init(ObjectClass *oc, void *data);
365    static void my_device_init(Object *obj);
366 
367    static const TypeInfo my_device_info = {
368        .parent = TYPE_DEVICE,
369        .name = TYPE_MY_DEVICE,
370        .instance_size = sizeof(MyDevice),
371        .instance_init = my_device_init,
372        .instance_finalize = my_device_finalize,
373        .class_size = sizeof(MyDeviceClass),
374        .class_init = my_device_class_init,
375    };
376 
377    static void
378    my_device_register_types(void)
379    {
380        type_register_static(&my_device_info);
381    }
382    type_init(my_device_register_types);
383 
384 This is sufficient to get the type registered with the type
385 system, and the three standard methods now need to be implemented
386 along with any other logic required for the type.
387 
388 If the type needs to implement one or more interfaces, then the
389 OBJECT_DEFINE_TYPE_WITH_INTERFACES() macro can be used instead.
390 This accepts an array of interface type names.
391 
392 .. code-block:: c
393    :caption: Defining a simple type implementing interfaces
394 
395    OBJECT_DEFINE_TYPE_WITH_INTERFACES(MyDevice, my_device,
396                                       MY_DEVICE, DEVICE,
397                                       { TYPE_USER_CREATABLE },
398                                       { NULL })
399 
400 If the type is not intended to be instantiated, then the
401 OBJECT_DEFINE_ABSTRACT_TYPE() macro can be used instead:
402 
403 .. code-block:: c
404    :caption: Defining a simple abstract type
405 
406    OBJECT_DEFINE_ABSTRACT_TYPE(MyDevice, my_device,
407                                MY_DEVICE, DEVICE)
408 
409 .. _device-life-cycle:
410 
411 Device Life-cycle
412 =================
413 
414 As class initialisation cannot fail devices have an two additional
415 methods to handle the creation of dynamic devices. The ``realize``
416 function is called with ``Error **`` pointer which should be set if
417 the device cannot complete its setup. Otherwise on successful
418 completion of the ``realize`` method the device object is added to the
419 QOM tree and made visible to the guest.
420 
421 The reverse function is ``unrealize`` and should be were clean-up
422 code lives to tidy up after the system is done with the device.
423 
424 All devices can be instantiated by C code, however only some can
425 created dynamically via the command line or monitor.
426 
427 Likewise only some can be unplugged after creation and need an
428 explicit ``unrealize`` implementation. This is determined by the
429 ``user_creatable`` variable in the root ``DeviceClass`` structure.
430 Devices can only be unplugged if their ``parent_bus`` has a registered
431 ``HotplugHandler``.
432 
433 API Reference
434 =============
435 
436 See the :ref:`QOM API<qom-api>` and :ref:`QDEV API<qdev-api>`
437 documents for the complete API description.
438