blob: 0fdf6846ddbf9529e8c0b8bb12c51687aa78b7de [file] [log] [blame]
Andrea Bolognani166d4342017-02-17 11:14:39 +01001# mach-virt - VirtIO guest (graphical console)
2# =========================================================
3#
4# Usage:
5#
6# $ qemu-system-aarch64 \
7# -nodefaults \
8# -readconfig mach-virt-graphical.cfg \
9# -cpu host
10#
11# You will probably need to tweak the lines marked as
12# CHANGE ME before being able to use this configuration!
13#
14# The guest will have a selection of VirtIO devices
15# tailored towards optimal performance with modern guests,
16# and will be accessed through a graphical console.
17#
18# ---------------------------------------------------------
19#
20# Using -nodefaults is required to have full control over
21# the virtual hardware: when it's specified, QEMU will
22# populate the board with only the builtin peripherals,
23# such as the PL011 UART, plus a PCI Express Root Bus; the
24# user will then have to explicitly add further devices.
25#
26# The PCI Express Root Bus shows up in the guest as:
27#
28# 00:00.0 Host bridge
29#
30# This configuration file adds a number of other useful
31# devices, more specifically:
32#
33# 00:01.0 Display controller
34# 00.1c.* PCI bridge (PCI Express Root Ports)
35# 01:00.0 SCSI storage controller
36# 02:00.0 Ethernet controller
37# 03:00.0 USB controller
38#
39# More information about these devices is available below.
40
41
42# Machine options
43# =========================================================
44#
45# We use the virt machine type and enable KVM acceleration
46# for better performance.
47#
48# Using less than 1 GiB of memory is probably not going to
49# yield good performance in the guest, and might even lead
50# to obscure boot issues in some cases.
51#
52# Unfortunately, there is no way to configure the CPU model
53# in this file, so it will have to be provided on the
54# command line, but we can configure the guest to use the
55# same GIC version as the host.
56
57[machine]
58 type = "virt"
59 accel = "kvm"
60 gic-version = "host"
61
62[memory]
63 size = "1024"
64
65
66# Firmware configuration
67# =========================================================
68#
69# There are two parts to the firmware: a read-only image
70# containing the executable code, which is shared between
71# guests, and a read/write variable store that is owned
72# by one specific guest, exclusively, and is used to
73# record information such as the UEFI boot order.
74#
75# For any new guest, its permanent, private variable store
76# should initially be copied from the template file
77# provided along with the firmware binary.
78#
79# Depending on the OS distribution you're using on the
80# host, the name of the package containing the firmware
81# binary and variable store template, as well as the paths
82# to the files themselves, will be different. For example:
83#
84# Fedora
85# edk2-aarch64 (pkg)
86# /usr/share/edk2/aarch64/QEMU_EFI-pflash.raw (bin)
87# /usr/share/edk2/aarch64/vars-template-pflash.raw (var)
88#
89# RHEL
90# AAVMF (pkg)
91# /usr/share/AAVMF/AAVMF_CODE.fd (bin)
92# /usr/share/AAVMF/AAVMF_VARS.fd (var)
93#
94# Debian/Ubuntu
95# qemu-efi (pkg)
96# /usr/share/AAVMF/AAVMF_CODE.fd (bin)
97# /usr/share/AAVMF/AAVMF_VARS.fd (var)
98
99[drive "uefi-binary"]
100 file = "/usr/share/AAVMF/AAVMF_CODE.fd" # CHANGE ME
101 format = "raw"
102 if = "pflash"
103 unit = "0"
104 readonly = "on"
105
106[drive "uefi-varstore"]
107 file = "guest_VARS.fd" # CHANGE ME
108 format = "raw"
109 if = "pflash"
110 unit = "1"
111
112
113# PCI bridge (PCI Express Root Ports)
114# =========================================================
115#
116# We create eight PCI Express Root Ports, and we plug them
117# all into separate functions of the same slot. Some of
118# them will be used by devices, the rest will remain
119# available for hotplug.
120
121[device "pcie.1"]
122 driver = "pcie-root-port"
123 bus = "pcie.0"
124 addr = "1c.0"
125 port = "1"
126 chassis = "1"
127 multifunction = "on"
128
129[device "pcie.2"]
130 driver = "pcie-root-port"
131 bus = "pcie.0"
132 addr = "1c.1"
133 port = "2"
134 chassis = "2"
135
136[device "pcie.3"]
137 driver = "pcie-root-port"
138 bus = "pcie.0"
139 addr = "1c.2"
140 port = "3"
141 chassis = "3"
142
143[device "pcie.4"]
144 driver = "pcie-root-port"
145 bus = "pcie.0"
146 addr = "1c.3"
147 port = "4"
148 chassis = "4"
149
150[device "pcie.5"]
151 driver = "pcie-root-port"
152 bus = "pcie.0"
153 addr = "1c.4"
154 port = "5"
155 chassis = "5"
156
157[device "pcie.6"]
158 driver = "pcie-root-port"
159 bus = "pcie.0"
160 addr = "1c.5"
161 port = "6"
162 chassis = "6"
163
164[device "pcie.7"]
165 driver = "pcie-root-port"
166 bus = "pcie.0"
167 addr = "1c.6"
168 port = "7"
169 chassis = "7"
170
171[device "pcie.8"]
172 driver = "pcie-root-port"
173 bus = "pcie.0"
174 addr = "1c.7"
175 port = "8"
176 chassis = "8"
177
178
179# SCSI storage controller (and storage)
180# =========================================================
181#
182# We use virtio-scsi here so that we can (hot)plug a large
183# number of disks without running into issues; a SCSI disk,
184# backed by a qcow2 disk image on the host's filesystem, is
185# attached to it.
186#
187# We also create an optical disk, mostly for installation
188# purposes: once the guest OS has been succesfully
189# installed, the guest will no longer boot from optical
190# media. If you don't want, or no longer want, to have an
191# optical disk in the guest you can safely comment out
192# all relevant sections below.
193
194[device "scsi"]
195 driver = "virtio-scsi-pci"
196 bus = "pcie.1"
197 addr = "00.0"
198
199[device "scsi-disk"]
200 driver = "scsi-hd"
201 bus = "scsi.0"
202 drive = "disk"
203 bootindex = "1"
204
205[drive "disk"]
206 file = "guest.qcow2" # CHANGE ME
207 format = "qcow2"
208 if = "none"
209
210[device "scsi-optical-disk"]
211 driver = "scsi-cd"
212 bus = "scsi.0"
213 drive = "optical-disk"
214 bootindex = "2"
215
216[drive "optical-disk"]
217 file = "install.iso" # CHANGE ME
218 format = "raw"
219 if = "none"
220
221
222# Ethernet controller
223# =========================================================
224#
225# We use virtio-net for improved performance over emulated
226# hardware; on the host side, we take advantage of user
227# networking so that the QEMU process doesn't require any
228# additional privileges.
229
230[netdev "hostnet"]
231 type = "user"
232
233[device "net"]
234 driver = "virtio-net-pci"
235 netdev = "hostnet"
236 bus = "pcie.2"
237 addr = "00.0"
238
239
240# USB controller (and input devices)
241# =========================================================
242#
243# We add a virtualization-friendly USB 3.0 controller and
244# a USB keyboard / USB tablet combo so that graphical
245# guests can be controlled appropriately.
246
247[device "usb"]
248 driver = "nec-usb-xhci"
249 bus = "pcie.3"
250 addr = "00.0"
251
252[device "keyboard"]
253 driver = "usb-kbd"
254 bus = "usb.0"
255
256[device "tablet"]
257 driver = "usb-tablet"
258 bus = "usb.0"
259
260
261# Display controller
262# =========================================================
263#
264# We use virtio-gpu because the legacy VGA framebuffer is
265# very troublesome on aarch64, and virtio-gpu is the only
266# video device that doesn't implement it.
267#
268# If you're running the guest on a remote, potentially
269# headless host, you will probably want to append something
270# like
271#
272# -display vnc=127.0.0.1:0
273#
274# to the command line in order to prevent QEMU from
275# creating a graphical display window on the host and
276# enable remote access instead.
277
278[device "video"]
279 driver = "virtio-gpu"
280 bus = "pcie.0"
281 addr = "01.0"