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 130Optional build dependencies 131 Build components whose absence does not affect the ability to build QEMU 132 may not be available in distros, or may be too old for our requirements. 133 Many of these, such as additional modules for the functional testing 134 framework or various linters, are written in Python and therefore can 135 also be installed using ``pip``. Cross compilers are another example 136 of optional build-time dependency; in this case it is possible to 137 download them from repositories such as EPEL, to use container-based 138 cross compilation using ``docker`` or ``podman``, or to use pre-built 139 binaries distributed with QEMU. 140 141Windows 142------- 143 144The project aims to support the two most recent versions of Windows that are 145still supported by the vendor. The minimum Windows API that is currently 146targeted is "Windows 8", so theoretically the QEMU binaries can still be run 147on older versions of Windows, too. However, such old versions of Windows are 148not tested anymore, so it is recommended to use one of the latest versions of 149Windows instead. 150 151The project supports building QEMU with current versions of the MinGW 152toolchain, either hosted on Linux (Debian/Fedora) or via `MSYS2`_ on Windows. 153A more recent Windows version is always preferred as it is less likely to have 154problems with building via MSYS2. The building process of QEMU involves some 155Python scripts that call os.symlink() which needs special attention for the 156build process to successfully complete. On newer versions of Windows 10, 157unprivileged accounts can create symlinks if Developer Mode is enabled. 158When Developer Mode is not available/enabled, the SeCreateSymbolicLinkPrivilege 159privilege is required, or the process must be run as an administrator. 160 161Only 64-bit Windows is supported. 162 163.. _Homebrew: https://brew.sh/ 164.. _MacPorts: https://www.macports.org/ 165.. _MSYS2: https://www.msys2.org/ 166.. _Repology: https://repology.org/ 167