QEMU and Kconfig¶
QEMU is a very versatile emulator; it can be built for a variety of targets, where each target can emulate various boards and at the same time different targets can share large amounts of code. For example, a POWER and an x86 board can run the same code to emulate a PCI network card, even though the boards use different PCI host bridges, and they can run the same code to emulate a SCSI disk while using different SCSI adapters. Arm, s390 and x86 boards can all present a virtio-blk disk to their guests, but with three different virtio guest interfaces.
Each QEMU target enables a subset of the boards, devices and buses that are included in QEMU’s source code. As a result, each QEMU executable only links a small subset of the files that form QEMU’s source code; anything that is not needed to support a particular target is culled.
QEMU uses a simple domain-specific language to describe the dependencies between components. This is useful for two reasons:
new targets and boards can be added without knowing in detail the architecture of the hardware emulation subsystems. Boards only have to list the components they need, and the compiled executable will include all the required dependencies and all the devices that the user can add to that board;
users can easily build reduced versions of QEMU that support only a subset of boards or devices. For example, by default most targets will include all emulated PCI devices that QEMU supports, but the build process is configurable and it is easy to drop unnecessary (or otherwise unwanted) code to make a leaner binary.
This domain-specific language is based on the Kconfig language that originated in the Linux kernel, though it was heavily simplified and the handling of dependencies is stricter in QEMU.
Unlike Linux, there is no user interface to edit the configuration, which
is instead specified in per-target files under the
directory of the QEMU source tree. This is because, unlike Linux,
configuration and dependencies can be treated as a black box when building
QEMU; the default configuration that QEMU ships with should be okay in
almost all cases.
The Kconfig language¶
Kconfig defines configurable components in files named
Note that configurable components are _not_ visible in C code as preprocessor
symbols; they are only visible in the Makefile. Each configurable component
defines a Makefile variable whose name starts with
All elements have boolean (true/false) type; truth is written as
falsehood is written
n. They are defined in a Kconfig
stanza like the following:
config ARM_VIRT bool imply PCI_DEVICES imply VFIO_AMD_XGBE imply VFIO_XGMAC select A15MPCORE select ACPI select ARM_SMMUV3
config keyword introduces a new configuration element. In the example
above, Makefiles will have access to a variable named
n (respectively for boolean true and false).
Boolean expressions can be used within the language, whenever
is written in the remainder of this section. The
! operators respectively denote conjunction (AND), disjunction (OR)
and negation (NOT).
bool data type declaration is optional, but it is suggested to
include it for clarity and future-proofing. After
bool the following
directives can be included:
depends on <expr>
This defines a dependency for this configurable element. Dependencies evaluate an expression and force the value of the variable to false if the expression is false.
select <symbol> [if <expr>]
depends oncan force a symbol to false, reverse dependencies can be used to force another symbol to true. In the following example,
CONFIG_BAZwill be true whenever
CONFIG_FOOis true:config FOO select BAZ
The optional expression will prevent
selectfrom having any effect unless it is true.
Note that unlike Linux’s Kconfig implementation, QEMU will detect contradictions between
selectstatements and prevent you from building such a configuration.
default <value> [if <expr>]
Default values are assigned to the config symbol if no other value was set by the user via
default-configs/*.makfiles, and only if
depends ondirectives do not force the value to true or false respectively.
n; it cannot be an arbitrary Boolean expression. However, a condition for applying the default value can be added with
A configuration element can have any number of default values (usually, if more than one default is present, they will have different conditions). If multiple default values satisfy their condition, only the first defined one is active.
reverse default (weak reverse dependency):
imply <symbol> [if <expr>]
This is similar to
selectas it applies a lower limit of
yto another symbol. However, the lower limit is only a default and the “implied” symbol’s value may still be set to
default-configs/*.makfiles. The following two examples are equivalent:config FOO bool imply BAZ config BAZ bool default y if FOO
The next section explains where to use
Guidelines for writing Kconfig files¶
Configurable elements in QEMU fall under five broad groups. Each group declares its dependencies in different ways:
subsystems, of which buses are a special case
Example:config SCSI bool
Subsystems always default to false (they have no
defaultdirective) and are never visible in
default-configs/*.makfiles. It’s up to other symbols to
selectwhatever subsystems they require.
They sometimes have
selectdirectives to bring in other required subsystems or buses. For example,
AUX(the DisplayPort auxiliary channel “bus”) selects
I2Cbecause it can act as an I2C master too.
Example:config MEGASAS_SCSI_PCI bool default y if PCI_DEVICES depends on PCI select SCSI
Devices are the most complex of the five. They can have a variety of directives that cooperate so that a default configuration includes all the devices that can be accessed from QEMU.
Devices depend on the bus that they lie on, for example a PCI device would specify
depends on PCI. An MMIO device will likely have no
depends ondirective. Devices also select the buses that the device provides, for example a SCSI adapter would specify
select SCSI. Finally, devices are usually
default yif and only if they have at least one
depends on; the default could be conditional on a device group.
Devices also select any optional subsystem that they use; for example a video card might specify
select EDIDif it needs to build EDID information and publish it to the guest.
Example:config PCI_DEVICES bool
Device groups provide a convenient mechanism to enable/disable many devices in one go. This is useful when a set of devices is likely to be enabled/disabled by several targets. Device groups usually need no directive and are not used in the Makefile either; they only appear as conditions for
QEMU currently has three device groups,
TEST_DEVICES. PCI devices usually have a
default y if PCI_DEVICESdirective rather than just
default y. This lets some boards (notably s390) easily support a subset of PCI devices, for example only VFIO (passthrough) and virtio-pci devices.
I2C_DEVICESis similar to
PCI_DEVICES. It contains i2c devices that users might reasonably want to plug in to an i2c bus on any board (and not ones which are very board-specific or that need to be wired up in a way that can’t be done on the command line).
TEST_DEVICESinstead is used for devices that are rarely used on production virtual machines, but provide useful hooks to test QEMU or KVM.
Example:config SUN4M bool imply TCX imply CG3 select CS4231 select ECCMEMCTL select EMPTY_SLOT select ESCC select ESP select FDC select SLAVIO select LANCE select M48T59 select STP2000
Boards specify their constituent devices using
selectdirectives. A device should be listed under
selectif the board cannot be started at all without it. It should be listed under
implyif (depending on the QEMU command line) the board may or may not be started without it. Boards also default to false; they are enabled by the
default-configs/*.makfor the target they apply to.
Example:config ECCMEMCTL bool select ECC
Internal elements group code that is useful in several boards or devices. They are usually enabled with
selectand in turn select other elements; they are never visible in
default-configs/*.makfiles, and often not even in the Makefile.
Writing and modifying default configurations¶
In addition to the Kconfig files under hw/, each target also includes
a file called
default-configs/TARGETNAME-softmmu.mak. These files
initialize some Kconfig variables to non-default values and provide the
starting point to turn on devices and subsystems.
A file in
default-configs/ looks like the following example:
# Default configuration for alpha-softmmu # Uncomment the following lines to disable these optional devices: # #CONFIG_PCI_DEVICES=n #CONFIG_TEST_DEVICES=n # Boards: # CONFIG_DP264=y
The first part, consisting of commented-out
=n assignments, tells
the user which devices or device groups are implied by the boards.
The second part, consisting of
=y assignments, tells the user which
boards are supported by the target. The user will typically modify
the default configuration by uncommenting lines in the first group,
or commenting out lines in the second group.
It is also possible to run QEMU’s configure script with the
--without-default-devices option. When this is done, everything defaults
n unless it is
selected or explicitly switched on in the
.mak files. In other words,
are disabled. When QEMU is built with this option, the user will probably
want to change some lines in the first group, for example like this:
and/or pick a subset of the devices in those device groups. Without
further modifications to
configs/devices/, a system emulator built
without default devices might not do much more than start an empty
machine, and even then only if
--nodefaults is specified on the
command line. Starting a VM without
--nodefaults is allowed to
fail, but should never abort. Failures in
make check with
--without-default-devices are considered bugs in the test code:
the tests should either use
--nodefaults, and should be skipped
if a necessary device is not present in the build. Such failures
should not be worked around with
Right now there is no single place that lists all the optional devices
CONFIG_TEST_DEVICES. In the future,
we expect that
.mak files will be automatically generated, so that
they will include all these symbols and some help text on what they do.
In some special cases, a configurable element depends on host features
that are detected by QEMU’s configure or
meson.build scripts; for
example some devices depend on the availability of KVM or on the presence
of a library on the host.
These symbols should be listed in
Kconfig.host like this:
config TPM bool
and also listed as follows in the top-level meson.build’s host_kconfig variable:
host_kconfig = \ (have_tpm ? ['CONFIG_TPM=y'] : ) + \ ('CONFIG_LINUX' in config_host ? ['CONFIG_LINUX=y'] : ) + \ (have_ivshmem ? ['CONFIG_IVSHMEM=y'] : ) + \ ...