docs/devel/kconfig.rst

13 SCSI adapters.  Arm, s390 and x86 boards can all present a virtio-blk
21 QEMU uses a simple domain-specific language to describe the dependencies
24 * new targets and boards can be added without knowing in detail the
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
36 This domain-specific language is based on the Kconfig language that
41 is instead specified in per-target files under the ``configs/``
44 QEMU; the default configuration that QEMU ships with should be okay in
48 --------------------
78 include it for clarity and future-proofing.  After ``bool`` the following
103 **default value**: ``default <value> [if <expr>]``
105   Default values are assigned to the config symbol if no other value was
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,
117 **reverse default** (weak reverse dependency): ``imply <symbol> [if <expr>]``
120   to another symbol.  However, the lower limit is only a default
131       default y if FOO
133   The next section explains where to use ``imply`` or ``default y``.
136 ------------------------------------
148   Subsystems always default to false (they have no ``default`` directive)
162       default y if PCI_DEVICES
167   of directives that cooperate so that a default configuration includes
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
179   a video card might specify ``select EDID`` if it needs to build EDID
193   as conditions for ``default y`` directives.
196   and ``TEST_DEVICES``.  PCI devices usually have a ``default y if
197   PCI_DEVICES`` directive rather than just ``default y``.  This lets
199   for example only VFIO (passthrough) and virtio-pci devices.
202   board (and not ones which are very board-specific or that need
214       default y
231   cannot be started at all without it.  It should be listed under
233   may not be started without it.  Boards default to true, but also
257 Writing and modifying default configurations
258 --------------------------------------------
261 a file called ``configs/TARGETNAME-softmmu.mak``.  These files
262 initialize some Kconfig variables to non-default values and provide the
267     # Default configuration for alpha-softmmu
278 The first part, consisting of commented-out ``=n`` assignments, tells
282 the default configuration by uncommenting lines in the first group,
286 ``--without-default-devices`` option.  When this is done, everything defaults
288 ``.mak`` files.  In other words, ``default`` and ``imply`` directives
295 and/or pick a subset of the devices in those device groups.  Without
297 without default devices might not do much more than start an empty
298 machine, and even then only if ``--nodefaults`` is specified on the
299 command line.  Starting a VM *without* ``--nodefaults`` is allowed to
301 ``--without-default-devices`` are considered bugs in the test code:
302 the tests should either use ``--nodefaults``, and should be skipped
303 if a necessary device is not present in the build.  Such failures
312 ----------------
314 In some special cases, a configurable element depends on host features
315 that are detected by QEMU's configure or ``meson.build`` scripts; for
324 and also listed as follows in the top-level meson.build's host_kconfig