]>
Commit | Line | Data |
---|---|---|
166d4346 AB |
1 | # 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" |