qapi: Require boxed for conditional command and event arguments
[qemu/armbru.git] / docs / devel / kconfig.rst
blobac9453eba909061d552bf61aa0cb7990afc823b9
1 .. _kconfig:
3 ================
4 QEMU and Kconfig
5 ================
7 QEMU is a very versatile emulator; it can be built for a variety of
8 targets, where each target can emulate various boards and at the same
9 time different targets can share large amounts of code.  For example,
10 a POWER and an x86 board can run the same code to emulate a PCI network
11 card, even though the boards use different PCI host bridges, and they
12 can run the same code to emulate a SCSI disk while using different
13 SCSI adapters.  Arm, s390 and x86 boards can all present a virtio-blk
14 disk to their guests, but with three different virtio guest interfaces.
16 Each QEMU target enables a subset of the boards, devices and buses that
17 are included in QEMU's source code.  As a result, each QEMU executable
18 only links a small subset of the files that form QEMU's source code;
19 anything that is not needed to support a particular target is culled.
21 QEMU uses a simple domain-specific language to describe the dependencies
22 between components.  This is useful for two reasons:
24 * new targets and boards can be added without knowing in detail the
25   architecture of the hardware emulation subsystems.  Boards only have
26   to list the components they need, and the compiled executable will
27   include all the required dependencies and all the devices that the
28   user can add to that board;
30 * users can easily build reduced versions of QEMU that support only a subset
31   of boards or devices.  For example, by default most targets will include
32   all emulated PCI devices that QEMU supports, but the build process is
33   configurable and it is easy to drop unnecessary (or otherwise unwanted)
34   code to make a leaner binary.
36 This domain-specific language is based on the Kconfig language that
37 originated in the Linux kernel, though it was heavily simplified and
38 the handling of dependencies is stricter in QEMU.
40 Unlike Linux, there is no user interface to edit the configuration, which
41 is instead specified in per-target files under the ``default-configs/``
42 directory of the QEMU source tree.  This is because, unlike Linux,
43 configuration and dependencies can be treated as a black box when building
44 QEMU; the default configuration that QEMU ships with should be okay in
45 almost all cases.
47 The Kconfig language
48 --------------------
50 Kconfig defines configurable components in files named ``hw/*/Kconfig``.
51 Note that configurable components are _not_ visible in C code as preprocessor
52 symbols; they are only visible in the Makefile.  Each configurable component
53 defines a Makefile variable whose name starts with ``CONFIG_``.
55 All elements have boolean (true/false) type; truth is written as ``y``, while
56 falsehood is written ``n``.  They are defined in a Kconfig
57 stanza like the following::
59       config ARM_VIRT
60          bool
61          imply PCI_DEVICES
62          imply VFIO_AMD_XGBE
63          imply VFIO_XGMAC
64          select A15MPCORE
65          select ACPI
66          select ARM_SMMUV3
68 The ``config`` keyword introduces a new configuration element.  In the example
69 above, Makefiles will have access to a variable named ``CONFIG_ARM_VIRT``,
70 with value ``y`` or ``n`` (respectively for boolean true and false).
72 Boolean expressions can be used within the language, whenever ``<expr>``
73 is written in the remainder of this section.  The ``&&``, ``||`` and
74 ``!`` operators respectively denote conjunction (AND), disjunction (OR)
75 and negation (NOT).
77 The ``bool`` data type declaration is optional, but it is suggested to
78 include it for clarity and future-proofing.  After ``bool`` the following
79 directives can be included:
81 **dependencies**: ``depends on <expr>``
83   This defines a dependency for this configurable element. Dependencies
84   evaluate an expression and force the value of the variable to false
85   if the expression is false.
87 **reverse dependencies**: ``select <symbol> [if <expr>]``
89   While ``depends on`` can force a symbol to false, reverse dependencies can
90   be used to force another symbol to true.  In the following example,
91   ``CONFIG_BAZ`` will be true whenever ``CONFIG_FOO`` is true::
93     config FOO
94       select BAZ
96   The optional expression will prevent ``select`` from having any effect
97   unless it is true.
99   Note that unlike Linux's Kconfig implementation, QEMU will detect
100   contradictions between ``depends on`` and ``select`` statements and prevent
101   you from building such a configuration.
103 **default value**: ``default <value> [if <expr>]``
105   Default values are assigned to the config symbol if no other value was
106   set by the user via ``default-configs/*.mak`` files, and only if
107   ``select`` or ``depends on`` directives do not force the value to true
108   or false respectively.  ``<value>`` can be ``y`` or ``n``; it cannot
109   be an arbitrary Boolean expression.  However, a condition for applying
110   the default value can be added with ``if``.
112   A configuration element can have any number of default values (usually,
113   if more than one default is present, they will have different
114   conditions). If multiple default values satisfy their condition,
115   only the first defined one is active.
117 **reverse default** (weak reverse dependency): ``imply <symbol> [if <expr>]``
119   This is similar to ``select`` as it applies a lower limit of ``y``
120   to another symbol.  However, the lower limit is only a default
121   and the "implied" symbol's value may still be set to ``n`` from a
122   ``default-configs/*.mak`` files.  The following two examples are
123   equivalent::
125     config FOO
126       bool
127       imply BAZ
129     config BAZ
130       bool
131       default y if FOO
133   The next section explains where to use ``imply`` or ``default y``.
135 Guidelines for writing Kconfig files
136 ------------------------------------
138 Configurable elements in QEMU fall under five broad groups.  Each group
139 declares its dependencies in different ways:
141 **subsystems**, of which **buses** are a special case
143   Example::
145     config SCSI
146       bool
148   Subsystems always default to false (they have no ``default`` directive)
149   and are never visible in ``default-configs/*.mak`` files.  It's
150   up to other symbols to ``select`` whatever subsystems they require.
152   They sometimes have ``select`` directives to bring in other required
153   subsystems or buses.  For example, ``AUX`` (the DisplayPort auxiliary
154   channel "bus") selects ``I2C`` because it can act as an I2C master too.
156 **devices**
158   Example::
160     config MEGASAS_SCSI_PCI
161       bool
162       default y if PCI_DEVICES
163       depends on PCI
164       select SCSI
166   Devices are the most complex of the five.  They can have a variety
167   of directives that cooperate so that a default configuration includes
168   all the devices that can be accessed from QEMU.
170   Devices *depend on* the bus that they lie on, for example a PCI
171   device would specify ``depends on PCI``.  An MMIO device will likely
172   have no ``depends on`` directive.  Devices also *select* the buses
173   that the device provides, for example a SCSI adapter would specify
174   ``select SCSI``.  Finally, devices are usually ``default y`` if and
175   only if they have at least one ``depends on``; the default could be
176   conditional on a device group.
178   Devices also select any optional subsystem that they use; for example
179   a video card might specify ``select EDID`` if it needs to build EDID
180   information and publish it to the guest.
182 **device groups**
184   Example::
186     config PCI_DEVICES
187       bool
189   Device groups provide a convenient mechanism to enable/disable many
190   devices in one go.  This is useful when a set of devices is likely to
191   be enabled/disabled by several targets.  Device groups usually need
192   no directive and are not used in the Makefile either; they only appear
193   as conditions for ``default y`` directives.
195   QEMU currently has three device groups, ``PCI_DEVICES``, ``I2C_DEVICES``,
196   and ``TEST_DEVICES``.  PCI devices usually have a ``default y if
197   PCI_DEVICES`` directive rather than just ``default y``.  This lets
198   some boards (notably s390) easily support a subset of PCI devices,
199   for example only VFIO (passthrough) and virtio-pci devices.
200   ``I2C_DEVICES`` is similar to ``PCI_DEVICES``. It contains i2c devices
201   that users might reasonably want to plug in to an i2c bus on any
202   board (and not ones which are very board-specific or that need
203   to be wired up in a way that can't be done on the command line).
204   ``TEST_DEVICES`` instead is used for devices that are rarely used on
205   production virtual machines, but provide useful hooks to test QEMU
206   or KVM.
208 **boards**
210   Example::
212     config SUN4M
213       bool
214       imply TCX
215       imply CG3
216       select CS4231
217       select ECCMEMCTL
218       select EMPTY_SLOT
219       select ESCC
220       select ESP
221       select FDC
222       select SLAVIO
223       select LANCE
224       select M48T59
225       select STP2000
227   Boards specify their constituent devices using ``imply`` and ``select``
228   directives.  A device should be listed under ``select`` if the board
229   cannot be started at all without it.  It should be listed under
230   ``imply`` if (depending on the QEMU command line) the board may or
231   may not be started without it.  Boards also default to false; they are
232   enabled by the ``default-configs/*.mak`` for the target they apply to.
234 **internal elements**
236   Example::
238     config ECCMEMCTL
239       bool
240       select ECC
242   Internal elements group code that is useful in several boards or
243   devices.  They are usually enabled with ``select`` and in turn select
244   other elements; they are never visible in ``default-configs/*.mak``
245   files, and often not even in the Makefile.
247 Writing and modifying default configurations
248 --------------------------------------------
250 In addition to the Kconfig files under hw/, each target also includes
251 a file called ``default-configs/TARGETNAME-softmmu.mak``.  These files
252 initialize some Kconfig variables to non-default values and provide the
253 starting point to turn on devices and subsystems.
255 A file in ``default-configs/`` looks like the following example::
257     # Default configuration for alpha-softmmu
259     # Uncomment the following lines to disable these optional devices:
260     #
261     #CONFIG_PCI_DEVICES=n
262     #CONFIG_TEST_DEVICES=n
264     # Boards:
265     #
266     CONFIG_DP264=y
268 The first part, consisting of commented-out ``=n`` assignments, tells
269 the user which devices or device groups are implied by the boards.
270 The second part, consisting of ``=y`` assignments, tells the user which
271 boards are supported by the target.  The user will typically modify
272 the default configuration by uncommenting lines in the first group,
273 or commenting out lines in the second group.
275 It is also possible to run QEMU's configure script with the
276 ``--without-default-devices`` option.  When this is done, everything defaults
277 to ``n`` unless it is ``select``\ ed or explicitly switched on in the
278 ``.mak`` files.  In other words, ``default`` and ``imply`` directives
279 are disabled.  When QEMU is built with this option, the user will probably
280 want to change some lines in the first group, for example like this::
282    CONFIG_PCI_DEVICES=y
283    #CONFIG_TEST_DEVICES=n
285 and/or pick a subset of the devices in those device groups.  Right now
286 there is no single place that lists all the optional devices for
287 ``CONFIG_PCI_DEVICES`` and ``CONFIG_TEST_DEVICES``.  In the future,
288 we expect that ``.mak`` files will be automatically generated, so that
289 they will include all these symbols and some help text on what they do.
291 ``Kconfig.host``
292 ----------------
294 In some special cases, a configurable element depends on host features
295 that are detected by QEMU's configure or ``meson.build`` scripts; for
296 example some devices depend on the availability of KVM or on the presence
297 of a library on the host.
299 These symbols should be listed in ``Kconfig.host`` like this::
301     config TPM
302       bool
304 and also listed as follows in the top-level meson.build's host_kconfig
305 variable::
307     host_kconfig = \
308       (have_tpm ? ['CONFIG_TPM=y'] : []) + \
309       ('CONFIG_LINUX' in config_host ? ['CONFIG_LINUX=y'] : []) + \
310       (have_ivshmem ? ['CONFIG_IVSHMEM=y'] : []) + \
311       ...