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 32Supported host architectures 33---------------------------- 34 35Those hosts are officially supported, with various accelerators: 36 37 .. list-table:: 38 :header-rows: 1 39 40 * - CPU Architecture 41 - Accelerators 42 * - Arm 43 - kvm (64 bit only), tcg, xen 44 * - MIPS (little endian only) 45 - kvm, tcg 46 * - PPC 47 - kvm, tcg 48 * - RISC-V 49 - kvm, tcg 50 * - s390x 51 - kvm, tcg 52 * - SPARC 53 - tcg 54 * - x86 55 - hax, hvf (64 bit only), kvm, nvmm, tcg, whpx (64 bit only), xen 56 57Other host architectures are not supported. It is possible to build QEMU system 58emulation on an unsupported host architecture using the configure 59``--enable-tcg-interpreter`` option to enable the TCI support, but note that 60this is very slow and is not recommended for normal use. QEMU user emulation 61requires host-specific support for signal handling, therefore TCI won't help 62on unsupported host architectures. 63 64Non-supported architectures may be removed in the future following the 65:ref:`deprecation process<Deprecated features>`. 66 67Linux OS, macOS, FreeBSD, NetBSD, OpenBSD 68----------------------------------------- 69 70The project aims to support the most recent major version at all times. Support 71for the previous major version will be dropped 2 years after the new major 72version is released or when the vendor itself drops support, whichever comes 73first. In this context, third-party efforts to extend the lifetime of a distro 74are not considered, even when they are endorsed by the vendor (eg. Debian LTS); 75the same is true of repositories that contain packages backported from later 76releases (e.g. Debian backports). Within each major release, only the most 77recent minor release is considered. 78 79For the purposes of identifying supported software versions available on Linux, 80the project will look at CentOS, Debian, Fedora, openSUSE, RHEL, SLES and 81Ubuntu LTS. Other distros will be assumed to ship similar software versions. 82 83For FreeBSD and OpenBSD, decisions will be made based on the contents of the 84respective ports repository, while NetBSD will use the pkgsrc repository. 85 86For macOS, `Homebrew`_ will be used, although `MacPorts`_ is expected to carry 87similar versions. 88 89Some build dependencies may follow less conservative rules: 90 91Python runtime 92 Distributions with long-term support often provide multiple versions 93 of the Python runtime. While QEMU will initially aim to support the 94 distribution's default runtime, it may later increase its minimum version 95 to any newer python that is available as an option from the vendor. 96 In this case, it will be necessary to use the ``--python`` command line 97 option of the ``configure`` script to point QEMU to a supported 98 version of the Python runtime. 99 100 As of QEMU |version|, the minimum supported version of Python is 3.6. 101 102Python build dependencies 103 Some of QEMU's build dependencies are written in Python. Usually these 104 are only packaged by distributions for the default Python runtime. 105 If QEMU bumps its minimum Python version and a non-default runtime is 106 required, it may be necessary to fetch python modules from the Python 107 Package Index (PyPI) via ``pip``, in order to build QEMU. 108 109Optional build dependencies 110 Build components whose absence does not affect the ability to build 111 QEMU may not be available in distros, or may be too old for QEMU's 112 requirements. Many of these, such as the Avocado testing framework 113 or various linters, are written in Python and therefore can also 114 be installed using ``pip``. Cross compilers are another example 115 of optional build-time dependency; in this case it is possible to 116 download them from repositories such as EPEL, to use container-based 117 cross compilation using ``docker`` or ``podman``, or to use pre-built 118 binaries distributed with QEMU. 119 120 121Windows 122------- 123 124The project aims to support the two most recent versions of Windows that are 125still supported by the vendor. The minimum Windows API that is currently 126targeted is "Windows 8", so theoretically the QEMU binaries can still be run 127on older versions of Windows, too. However, such old versions of Windows are 128not tested anymore, so it is recommended to use one of the latest versions of 129Windows instead. 130 131The project supports building QEMU with current versions of the MinGW 132toolchain, either hosted on Linux (Debian/Fedora) or via `MSYS2`_ on Windows. 133A more recent Windows version is always preferred as it is less likely to have 134problems with building via MSYS2. The building process of QEMU involves some 135Python scripts that call os.symlink() which needs special attention for the 136build process to successfully complete. On newer versions of Windows 10, 137unprivileged accounts can create symlinks if Developer Mode is enabled. 138When Developer Mode is not available/enabled, the SeCreateSymbolicLinkPrivilege 139privilege is required, or the process must be run as an administrator. 140 141.. _Homebrew: https://brew.sh/ 142.. _MacPorts: https://www.macports.org/ 143.. _MSYS2: https://www.msys2.org/ 144.. _Repology: https://repology.org/ 145