xref: /openbmc/qemu/docs/about/build-platforms.rst (revision b6f1244678bebaf7e2c775cfc66d452f95678ebf)
1.. _Supported-build-platforms:
2
3Supported build platforms
4=========================
5
6QEMU aims to support building and executing on multiple host OS
7platforms. This appendix outlines which platforms are the major build
8targets. These platforms are used as the basis for deciding upon the
9minimum required versions of 3rd party software QEMU depends on. The
10supported platforms are the targets for automated testing performed by
11the project when patches are submitted for review, and tested before and
12after merge.
13
14If a platform is not listed here, it does not imply that QEMU won't
15work. If an unlisted platform has comparable software versions to a
16listed platform, there is every expectation that it will work. Bug
17reports are welcome for problems encountered on unlisted platforms
18unless they are clearly older vintage than what is described here.
19
20Note that when considering software versions shipped in distros as
21support targets, QEMU considers only the version number, and assumes the
22features in that distro match the upstream release with the same
23version. In other words, if a distro backports extra features to the
24software in their distro, QEMU upstream code will not add explicit
25support for those backports, unless the feature is auto-detectable in a
26manner that works for the upstream releases too.
27
28The `Repology`_ site is a useful resource to identify
29currently shipped versions of software in various operating systems,
30though it does not cover all distros listed below.
31
32You can find how to install build dependencies for different systems on the
33:ref:`setup-build-env` page.
34
35Supported host architectures
36----------------------------
37
38Those hosts are officially supported, with various accelerators:
39
40  .. list-table::
41   :header-rows: 1
42
43   * - CPU Architecture
44     - Accelerators
45   * - Arm
46     - hvf (64 bit only), kvm (64 bit only), tcg, xen
47   * - MIPS (64 bit little endian only)
48     - kvm, tcg
49   * - PPC
50     - kvm, tcg
51   * - RISC-V
52     - kvm, tcg
53   * - s390x
54     - kvm, tcg
55   * - SPARC
56     - tcg
57   * - x86
58     - hvf (64 bit only), kvm, nvmm, tcg, whpx (64 bit only), xen
59
60Other host architectures are not supported. It is possible to build QEMU system
61emulation on an unsupported host architecture using the configure
62``--enable-tcg-interpreter`` option to enable the TCI support, but note that
63this is very slow and is not recommended for normal use. QEMU user emulation
64requires host-specific support for signal handling, therefore TCI won't help
65on unsupported host architectures.
66
67Non-supported architectures may be removed in the future following the
68:ref:`deprecation process<Deprecated features>`.
69
70Linux OS, macOS, FreeBSD, NetBSD, OpenBSD
71-----------------------------------------
72
73The project aims to support the most recent major version at all times for
74up to five years after its initial release. Support
75for the previous major version will be dropped 2 years after the new major
76version is released or when the vendor itself drops support, whichever comes
77first. In this context, third-party efforts to extend the lifetime of a distro
78are not considered, even when they are endorsed by the vendor (eg. Debian LTS);
79the same is true of repositories that contain packages backported from later
80releases (e.g. Debian backports). Within each major release, only the most
81recent minor release is considered.
82
83For the purposes of identifying supported software versions available on Linux,
84the project will look at CentOS, Debian, Fedora, openSUSE, RHEL, SLES and
85Ubuntu LTS. Other distros will be assumed to ship similar software versions.
86
87For FreeBSD and OpenBSD, decisions will be made based on the contents of the
88respective ports repository, while NetBSD will use the pkgsrc repository.
89
90For macOS, `Homebrew`_ will be used, although `MacPorts`_ is expected to carry
91similar versions.
92
93Some build dependencies may follow less conservative rules:
94
95Python runtime
96  Distributions with long-term support often provide multiple versions
97  of the Python runtime.  While QEMU will initially aim to support the
98  distribution's default runtime, it may later increase its minimum version
99  to any newer python that is available as an option from the vendor.
100  In this case, it will be necessary to use the ``--python`` command line
101  option of the ``configure`` script to point QEMU to a supported
102  version of the Python runtime.
103
104  As of QEMU |version|, the minimum supported version of Python is 3.9.
105
106Python build dependencies
107  Some of QEMU's build dependencies are written in Python.  Usually these
108  are only packaged by distributions for the default Python runtime.
109  If QEMU bumps its minimum Python version and a non-default runtime is
110  required, it may be necessary to fetch python modules from the Python
111  Package Index (PyPI) via ``pip``, in order to build QEMU.
112
113Rust build dependencies
114  QEMU is generally conservative in adding new Rust dependencies, and all
115  of them are included in the distributed tarballs.  One exception is the
116  bindgen tool, which is too big to package and distribute.  The minimum
117  supported version of bindgen is 0.60.x.  For distributions that do not
118  include bindgen or have an older version, it is recommended to install
119  a newer version using ``cargo install bindgen-cli``.
120
121  QEMU requires Rust 1.77.0.  This is available on all supported platforms
122  with one exception, namely the ``mips64el`` architecture on Debian bookworm.
123  For all other architectures, Debian bookworm provides a new-enough Rust
124  compiler in the ``rustc-web`` package.
125
126  Also, on Ubuntu 22.04 or 24.04 this requires the ``rustc-1.77``
127  (or newer) package.  The path to ``rustc`` and ``rustdoc`` must be
128  provided manually to the configure script.
129
130  Some distros prefer to avoid vendored crate sources, and instead use
131  local sources from e.g. ``/usr/share/cargo/registry``.  QEMU includes a
132  script, ``scripts/get-wraps-from-cargo-registry.py``, that automatically
133  performs this task.  The script is meant to be invoked after unpacking
134  the QEMU tarball.  QEMU also includes ``rust/Cargo.toml`` and
135  ``rust/Cargo.lock`` files that can be used to compute QEMU's build
136  dependencies, e.g. using ``cargo2rpm -p rust/Cargo.toml buildrequires``.
137
138Optional build dependencies
139  Build components whose absence does not affect the ability to build QEMU
140  may not be available in distros, or may be too old for our requirements.
141  Many of these, such as additional modules for the functional testing
142  framework or various linters, are written in Python and therefore can
143  also be installed using ``pip``.  Cross compilers are another example
144  of optional build-time dependency; in this case it is possible to
145  download them from repositories such as EPEL, to use container-based
146  cross compilation using ``docker`` or ``podman``, or to use pre-built
147  binaries distributed with QEMU.
148
149Windows
150-------
151
152The project aims to support the two most recent versions of Windows that are
153still supported by the vendor. The minimum Windows API that is currently
154targeted is "Windows 8", so theoretically the QEMU binaries can still be run
155on older versions of Windows, too. However, such old versions of Windows are
156not tested anymore, so it is recommended to use one of the latest versions of
157Windows instead.
158
159The project supports building QEMU with current versions of the MinGW
160toolchain, either hosted on Linux (Debian/Fedora) or via `MSYS2`_ on Windows.
161A more recent Windows version is always preferred as it is less likely to have
162problems with building via MSYS2. The building process of QEMU involves some
163Python scripts that call os.symlink() which needs special attention for the
164build process to successfully complete. On newer versions of Windows 10,
165unprivileged accounts can create symlinks if Developer Mode is enabled.
166When Developer Mode is not available/enabled, the SeCreateSymbolicLinkPrivilege
167privilege is required, or the process must be run as an administrator.
168
169Only 64-bit Windows is supported.
170
171.. _Homebrew: https://brew.sh/
172.. _MacPorts: https://www.macports.org/
173.. _MSYS2: https://www.msys2.org/
174.. _Repology: https://repology.org/
175