system/arm/virt.rst

4 The ``virt`` board is a platform which does not correspond to any
7 a guest such as Linux and do not care about reproducing the
8 idiosyncrasies and limitations of a particular bit of real-world
11 This is a "versioned" board model, so as well as the ``virt`` machine
13 changes between QEMU versions) a version is provided that guarantees
16 ``virt-5.0`` machine type will behave like the ``virt`` machine from
17 the QEMU 5.0 release, and migration should work between ``virt-5.0``
18 of the 5.0 release and ``virt-5.0`` of the 5.1 release. Migration
20 the non-versioned ``virt`` machine type.
27 - PCI/PCIe devices
28 - Flash memory
29 - Either one or two PL011 UARTs for the NonSecure World
30 - An RTC
31 - The fw_cfg device that allows a guest to obtain data from QEMU
32 - A PL061 GPIO controller
33 - An optional SMMUv3 IOMMU
34 - hotpluggable DIMMs
35 - hotpluggable NVDIMMs
36 - An MSI controller (GICv2M or ITS). GICv2M is selected by default along
37   with GICv2. ITS is selected by default with GICv3 (>= virt-2.7). Note
39 - 32 virtio-mmio transport devices
40 - running guests using the KVM accelerator on aarch64 hardware
41 - large amounts of RAM (at least 255GB, and more if using highmem)
42 - many CPUs (up to 512 if using a GICv3 and highmem)
43 - Secure-World-only devices if the CPU has TrustZone:
45   - A second PL011 UART
46   - A second PL061 GPIO controller, with GPIO lines for triggering
47     a system reset or system poweroff
48   - A secure flash memory
49   - 16MB of secure RAM
51 The second NonSecure UART only exists if a backend is configured
52 explicitly (e.g. with a second -serial command line option) and
57 - ``cortex-a7`` (32-bit)
58 - ``cortex-a15`` (32-bit; the default)
59 - ``cortex-a35`` (64-bit)
60 - ``cortex-a53`` (64-bit)
61 - ``cortex-a55`` (64-bit)
62 - ``cortex-a57`` (64-bit)
63 - ``cortex-a72`` (64-bit)
64 - ``cortex-a76`` (64-bit)
65 - ``cortex-a710`` (64-bit)
66 - ``a64fx`` (64-bit)
67 - ``host`` (with KVM only)
68 - ``neoverse-n1`` (64-bit)
69 - ``neoverse-v1`` (64-bit)
70 - ``neoverse-n2`` (64-bit)
71 - ``max`` (same as ``host`` for KVM; best possible emulation with TCG)
73 Note that the default is ``cortex-a15``, so for an AArch64 guest you must
74 specify a CPU type.
76 Also, please note that passing ``max`` CPU (i.e. ``-cpu max``) won't
77 enable all the CPU features for a given ``virt`` machine. Where a CPU
80 but instead requires a machine option to enable it.
82 For example, MTE support must be enabled with ``-machine virt,mte=on``,
83 as well as by selecting an MTE-capable CPU (e.g., ``max``) with the
84 ``-cpu`` option.
86 See the machine-specific options below, or check them for a given machine
87 by passing the ``help`` suboption, like: ``-machine virt-9.0,help``.
91 the Display devices section of "-device help". The recommended option
92 is ``virtio-gpu-pci``; this is the only one which will work correctly
96 Machine-specific options
99 The following machine-specific options are supported:
102   Set ``on``/``off`` to enable/disable emulating a guest CPU which implements the
106   Set ``on``/``off`` to enable/disable emulating a guest CPU which implements the
110   Set ``on``/``off`` to enable/disable emulating a guest CPU which implements the
116   later than ``virt-2.12`` when the CPU supports an address space
117   bigger than 32 bits (i.e. 64-bit CPUs, and 32-bit CPUs with the
119   boot a 32-bit kernel which does not have ``CONFIG_LPAE`` enabled on
120   a CPU type which implements LPAE, you will need to manually set
124 compact-highmem
126   The default is ``on`` for machine types later than ``virt-7.2``.
128 highmem-redists
133 highmem-ecam
135   The default is ``on`` for machine types later than ``virt-3.0``.
137 highmem-mmio
141 gic-version
160   for machine types later than ``virt-2.7``.
171   Set ``on``/``off`` to enable/disable reporting host memory errors to a guest
174 dtb-randomness
176   rng-seed and kaslr-seed nodes (in both "/chosen" and
177   "/secure-chosen") to use for features like the random number
181   DTB to be non-deterministic. It would be the responsibility of
182   the firmware to come up with a seed and pass it on if it wants to.
184 dtb-kaslr-seed
185   A deprecated synonym for dtb-randomness.
192 kernel versions, especially for 32-bit Arm, did not have everything
200 If you want to use the ``virtio-gpu-pci`` graphics device you will also
206 Hardware configuration information for bare-metal programming
209 The ``virt`` board automatically generates a device tree blob ("dtb")
212 in the system. Guest code can rely on and hard-code the following
215 - Flash memory starts at address 0x0000_0000
217 - RAM starts at 0x4000_0000
225 - For guests using the Linux kernel boot protocol (this means any
226   non-ELF file passed to the QEMU ``-kernel`` option) the address
227   of the DTB is passed in a register (``r2`` for 32-bit guests,
228   or ``x0`` for 64-bit guests)
230 - For guests booting as "bare-metal" (any other kind of boot),