]>
Commit | Line | Data |
---|---|---|
49ba9447 | 1 | \r |
2 | === OVMF OVERVIEW ===\r | |
3 | \r | |
4 | The Open Virtual Machine Firmware (OVMF) project aims\r | |
5 | to support firmware for Virtual Machines using the edk2\r | |
6 | code base. More information can be found at:\r | |
7 | \r | |
9a426abc | 8 | http://www.tianocore.org/ovmf/\r |
49ba9447 | 9 | \r |
10 | === STATUS ===\r | |
11 | \r | |
49ba9447 | 12 | Current capabilities:\r |
13 | * IA32 and X64 architectures\r | |
ae4aa4a3 | 14 | * QEMU (version 1.7.1 or later, with 1.7 or later machine types)\r |
49ba9447 | 15 | - Video, keyboard, IDE, CD-ROM, serial\r |
16 | - Runs UEFI shell\r | |
ae4aa4a3 | 17 | - Optional NIC support.\r |
73f4a1c0 | 18 | * UEFI Linux boots\r |
19 | * UEFI Windows 8 boots\r | |
90803342 | 20 | * UEFI Windows 7 & Windows 2008 Server boot (see important notes below!)\r |
49ba9447 | 21 | \r |
22 | === FUTURE PLANS ===\r | |
23 | \r | |
49ba9447 | 24 | * Test/Stabilize UEFI Self-Certification Tests (SCT) results\r |
25 | \r | |
37e97c51 | 26 | === BUILDING OVMF ===\r |
27 | \r | |
28 | Pre-requisites:\r | |
29 | * Build environment capable of build the edk2 MdeModulePkg.\r | |
66325870 | 30 | * A properly configured ASL compiler:\r |
31 | - Intel ASL compiler: Available from http://www.acpica.org\r | |
32 | - Microsoft ASL compiler: Available from http://www.acpi.info\r | |
497cbb53 | 33 | * NASM: http://www.nasm.us/\r |
37e97c51 | 34 | \r |
35 | Update Conf/target.txt ACTIVE_PLATFORM for OVMF:\r | |
36 | PEI arch DXE arch UEFI interfaces\r | |
37 | * OvmfPkg/OvmfPkgIa32.dsc IA32 IA32 IA32\r | |
38 | * OvmfPkg/OvmfPkgIa32X64.dsc IA32 X64 X64\r | |
39 | * OvmfPkg/OvmfPkgX64.dsc X64 X64 X64\r | |
40 | \r | |
2dae09a5 | 41 | Update Conf/target.txt TARGET_ARCH based on the .dsc file:\r |
42 | TARGET_ARCH\r | |
43 | * OvmfPkg/OvmfPkgIa32.dsc IA32\r | |
44 | * OvmfPkg/OvmfPkgIa32X64.dsc IA32 X64\r | |
45 | * OvmfPkg/OvmfPkgX64.dsc X64\r | |
46 | \r | |
47 | Following the edk2 build process, you will find the OVMF binaries\r | |
48 | under the $WORKSPACE/Build/*/*/FV directory. The actual path will\r | |
49 | depend on how your build is configured. You can expect to find\r | |
50 | these binary outputs:\r | |
7416f4eb | 51 | * OVMF.FD\r |
66325870 | 52 | - Please note! This filename has changed. Older releases used OVMF.Fv.\r |
922f593a | 53 | * OvmfVideo.rom\r |
e79095b7 | 54 | - This file is not built separately any longer, starting with svn r13520.\r |
2dae09a5 | 55 | \r |
316e6df4 MK |
56 | If you are new to building in edk2 or looking for the latest build\r |
57 | instructions, visit https://github.com/tianocore/tianocore.github.io/wiki/Build-Instructions\r | |
58 | \r | |
59 | More OVMF-specific build information can be found at:\r | |
c315da0a | 60 | \r |
9a426abc | 61 | https://github.com/tianocore/tianocore.github.io/wiki/How%20to%20build%20OVMF\r |
37e97c51 | 62 | \r |
63 | === RUNNING OVMF on QEMU ===\r | |
64 | \r | |
558d83ab | 65 | * Be sure to use qemu-system-x86_64, if you are using an X64 firmware.\r |
37e97c51 | 66 | (qemu-system-x86_64 works for the IA32 firmware as well, of course.)\r |
210c880f | 67 | * Use OVMF for QEMU firmware (3 options available)\r |
ae4aa4a3 | 68 | - Option 1: Use QEMU -pflash parameter\r |
210c880f JJ |
69 | * QEMU/OVMF will use emulated flash, and fully support UEFI variables\r |
70 | * Run qemu with: -pflash path/to/OVMF.fd\r | |
8714a631 LE |
71 | * Note that this option is required for running SecureBoot-enabled builds\r |
72 | (-D SECURE_BOOT_ENABLE).\r | |
210c880f JJ |
73 | - Option 2: Use QEMU -bios parameter\r |
74 | * Note that UEFI variables will be partially emulated, and non-volatile\r | |
75 | variables may lose their contents after a reboot\r | |
76 | * Run qemu with: -bios path/to/OVMF.fd\r | |
77 | - Option 3: Use QEMU -L parameter\r | |
78 | * Note that UEFI variables will be partially emulated, and non-volatile\r | |
79 | variables may lose their contents after a reboot\r | |
80 | * Either copy, rename or symlink OVMF.fd => bios.bin\r | |
81 | * Use the QEMU -L parameter to specify the directory where the bios.bin\r | |
82 | file is located.\r | |
37e97c51 | 83 | * The EFI shell is built into OVMF builds at this time, so it should\r |
84 | run automatically if a UEFI boot application is not found on the\r | |
85 | removable media.\r | |
aed8e2ec | 86 | * On Linux, newer version of QEMU may enable KVM feature, and this might\r |
87 | cause OVMF to fail to boot. The QEMU '-no-kvm' may allow OVMF to boot.\r | |
bf23b44d | 88 | * Capturing OVMF debug messages on qemu:\r |
89 | - The default OVMF build writes debug messages to IO port 0x402. The\r | |
90 | following qemu command line options save them in the file called\r | |
91 | debug.log: '-debugcon file:debug.log -global isa-debugcon.iobase=0x402'.\r | |
92 | - It is possible to revert to the original behavior, when debug messages were\r | |
93 | written to the emulated serial port (potentially intermixing OVMF debug\r | |
94 | output with UEFI serial console output). For this the\r | |
95 | '-D DEBUG_ON_SERIAL_PORT' option has to be passed to the build command (see\r | |
96 | the next section), and in order to capture the serial output qemu needs to\r | |
97 | be started with eg. '-serial file:serial.log'.\r | |
98 | - Debug messages fall into several categories. Logged vs. suppressed\r | |
99 | categories are controlled at OVMF build time by the\r | |
100 | 'gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel' bitmask (an UINT32\r | |
101 | value) in the selected .dsc file. Individual bits of this bitmask are\r | |
102 | defined in <MdePkg/Include/Library/DebugLib.h>. One non-default bit (with\r | |
103 | some performance impact) that is frequently set for debugging is 0x00400000\r | |
104 | (DEBUG_VERBOSE).\r | |
105 | - The RELEASE build target ('-b RELEASE' build option, see below) disables\r | |
106 | all debug messages. The default build target is DEBUG.\r | |
5a9745b9 | 107 | \r |
108 | === Build Scripts ===\r | |
109 | \r | |
66325870 | 110 | On systems with the bash shell you can use OvmfPkg/build.sh to simplify\r |
111 | building and running OVMF.\r | |
5a9745b9 | 112 | \r |
113 | So, for example, to build + run OVMF X64:\r | |
66325870 | 114 | $ OvmfPkg/build.sh -a X64\r |
115 | $ OvmfPkg/build.sh -a X64 qemu\r | |
5a9745b9 | 116 | \r |
117 | And to run a 64-bit UEFI bootable ISO image:\r | |
66325870 | 118 | $ OvmfPkg/build.sh -a X64 qemu -cdrom /path/to/disk-image.iso\r |
119 | \r | |
8d7cdfae LE |
120 | To build a 32-bit OVMF without debug messages using GCC 4.8:\r |
121 | $ OvmfPkg/build.sh -a IA32 -b RELEASE -t GCC48\r | |
5a9745b9 | 122 | \r |
5e04f4b7 LE |
123 | === SMM support ===\r |
124 | \r | |
125 | Requirements:\r | |
126 | * SMM support requires QEMU 2.5.\r | |
127 | * The minimum required QEMU machine type is "pc-q35-2.5".\r | |
128 | * SMM with KVM requires Linux 4.4 (host).\r | |
129 | \r | |
130 | OVMF is capable of utilizing SMM if the underlying QEMU or KVM hypervisor\r | |
131 | emulates SMM. SMM is put to use in the S3 suspend and resume infrastructure,\r | |
132 | and in the UEFI variable driver stack. The purpose is (virtual) hardware\r | |
133 | separation between the runtime guest OS and the firmware (OVMF), with the\r | |
134 | intent to make Secure Boot actually secure, by preventing the runtime guest OS\r | |
135 | from tampering with the variable store and S3 areas.\r | |
136 | \r | |
137 | For SMM support, OVMF must be built with the "-D SMM_REQUIRE" option. The\r | |
138 | resultant firmware binary will check if QEMU actually provides SMM emulation;\r | |
139 | if it doesn't, then OVMF will log an error and trigger an assertion failure\r | |
140 | during boot (even in RELEASE builds). Both the naming of the flag (SMM_REQUIRE,\r | |
141 | instead of SMM_ENABLE), and this behavior are consistent with the goal\r | |
142 | described above: this is supposed to be a security feature, and fallbacks are\r | |
143 | not allowed. Similarly, a pflash-backed variable store is a requirement.\r | |
144 | \r | |
145 | QEMU should be started with the options listed below (in addition to any other\r | |
146 | guest-specific flags). The command line should be gradually composed from the\r | |
147 | hints below. '\' is used to extend the command line to multiple lines, and '^'\r | |
148 | can be used on Windows.\r | |
149 | \r | |
150 | * QEMU binary and options specific to 32-bit guests:\r | |
151 | \r | |
152 | $ qemu-system-i386 -cpu coreduo,-nx \\r | |
153 | \r | |
154 | or\r | |
155 | \r | |
156 | $ qemu-system-x86_64 -cpu <MODEL>,-lm,-nx \\r | |
157 | \r | |
158 | * QEMU binary for running 64-bit guests (no particular options):\r | |
159 | \r | |
160 | $ qemu-system-x86_64 \\r | |
161 | \r | |
162 | * Flags common to all SMM scenarios (only the Q35 machine type is supported):\r | |
163 | \r | |
164 | -machine q35,smm=on,accel=(tcg|kvm) \\r | |
165 | -m ... \\r | |
166 | -smp ... \\r | |
167 | -global driver=cfi.pflash01,property=secure,value=on \\r | |
168 | -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on \\r | |
169 | -drive if=pflash,format=raw,unit=1,file=copy_of_OVMF_VARS.fd \\r | |
170 | \r | |
171 | * In order to disable S3, add:\r | |
172 | \r | |
173 | -global ICH9-LPC.disable_s3=1 \\r | |
174 | \r | |
aed8e2ec | 175 | === Network Support ===\r |
176 | \r | |
7a1f5947 LE |
177 | OVMF provides a UEFI network stack by default. Its lowest level driver is the\r |
178 | NIC driver, higher levels are generic. In order to make DHCP, PXE Boot, and eg.\r | |
179 | socket test utilities from the StdLib edk2 package work, (1) qemu has to be\r | |
180 | configured to emulate a NIC, (2) a matching UEFI NIC driver must be available\r | |
181 | when OVMF boots.\r | |
7628b0f5 | 182 | \r |
183 | (If a NIC is configured for the virtual machine, and -- dependent on boot order\r | |
184 | -- PXE booting is attempted, but no DHCP server responds to OVMF's DHCP\r | |
185 | DISCOVER message at startup, the boot process may take approx. 3 seconds\r | |
186 | longer.)\r | |
187 | \r | |
188 | * For each NIC emulated by qemu, a GPLv2 licensed UEFI driver is available from\r | |
ae4aa4a3 LE |
189 | the iPXE project. The qemu source distribution contains prebuilt binaries of\r |
190 | these drivers (and of course allows one to rebuild them from source as well).\r | |
191 | This is the recommended set of drivers.\r | |
7628b0f5 | 192 | \r |
193 | * Use the qemu -netdev and -device options, or the legacy -net option, to\r | |
194 | enable NIC support: <http://wiki.qemu.org/Documentation/Networking>.\r | |
195 | \r | |
ae4aa4a3 LE |
196 | * The iPXE drivers are automatically available to and configured for OVMF in\r |
197 | the default qemu installation.\r | |
7628b0f5 | 198 | \r |
7a1f5947 LE |
199 | * Independently of the iPXE NIC drivers, the default OVMF build provides a\r |
200 | basic virtio-net driver, located in OvmfPkg/VirtioNetDxe.\r | |
201 | \r | |
202 | * Also independently of the iPXE NIC drivers, Intel's proprietary E1000 NIC\r | |
253d81c7 LE |
203 | driver (from the BootUtil distribution) can be embedded in the OVMF image at\r |
204 | build time:\r | |
205 | \r | |
206 | - Download BootUtil:\r | |
207 | - Navigate to\r | |
208 | https://downloadcenter.intel.com/download/19186/Ethernet-Intel-Ethernet-Connections-Boot-Utility-Preboot-Images-and-EFI-Drivers\r | |
209 | - Click the download link for "PREBOOT.EXE".\r | |
210 | - Accept the Intel Software License Agreement that appears.\r | |
211 | - Unzip "PREBOOT.EXE" into a separate directory (this works with the\r | |
212 | "unzip" utility on platforms different from Windows as well).\r | |
213 | - Copy the "APPS/EFI/EFIx64/E3522X2.EFI" driver binary to\r | |
214 | "Intel3.5/EFIX64/E3522X2.EFI" in your WORKSPACE.\r | |
215 | - Intel have stopped distributing an IA32 driver binary (which used to\r | |
216 | match the filename pattern "E35??E2.EFI"), thus this method will only\r | |
217 | work for the IA32X64 and X64 builds of OVMF.\r | |
7628b0f5 | 218 | \r |
219 | - Include the driver in OVMF during the build:\r | |
253d81c7 LE |
220 | - Add "-D E1000_ENABLE" to your build command (only when building\r |
221 | "OvmfPkg/OvmfPkgIa32X64.dsc" or "OvmfPkg/OvmfPkgX64.dsc").\r | |
e3dca185 | 222 | - For example: "build -D E1000_ENABLE".\r |
aed8e2ec | 223 | \r |
7a1f5947 LE |
224 | * When a matching iPXE driver is configured for a NIC as described above, it\r |
225 | takes priority over other drivers that could possibly drive the card too:\r | |
226 | \r | |
253d81c7 LE |
227 | | e1000 ne2k_pci pcnet rtl8139 virtio-net-pci\r |
228 | ---------------------+------------------------------------------------\r | |
229 | iPXE | x x x x x\r | |
230 | VirtioNetDxe | x\r | |
231 | Intel BootUtil (X64) | x\r | |
7a1f5947 | 232 | \r |
d3180516 GL |
233 | === HTTPS Boot ===\r |
234 | \r | |
235 | HTTPS Boot is an alternative solution to PXE. It replaces the tftp server\r | |
236 | with a HTTPS server so the firmware can download the images through a trusted\r | |
237 | and encrypted connection.\r | |
238 | \r | |
1631bb26 GL |
239 | * To enable HTTPS Boot, you have to build OVMF with -D NETWORK_HTTP_BOOT_ENABLE\r |
240 | and -D NETWORK_TLS_ENABLE. The former brings in the HTTP stack from\r | |
241 | NetworkPkg while the latter enables TLS support in both NetworkPkg and\r | |
242 | CryptoPkg.\r | |
243 | \r | |
244 | If you want to exclude the unsecured HTTP connection completely, OVMF has to\r | |
245 | be built with -D NETWORK_ALLOW_HTTP_CONNECTIONS=FALSE so that only the HTTPS\r | |
246 | connections will be accepted.\r | |
d3180516 GL |
247 | \r |
248 | * By default, there is no trusted certificate. The user has to import the\r | |
249 | certificates either manually with "Tls Auth Configuration" utility in the\r | |
250 | firmware UI or through the fw_cfg entry, etc/edk2/https/cacerts.\r | |
251 | \r | |
252 | -fw_cfg name=etc/edk2/https/cacerts,file=<certdb>\r | |
253 | \r | |
254 | The blob for etc/edk2/https/cacerts has to be in the format of Signature\r | |
255 | Database(*1). You can use p11-kit(*2) or efisiglit(*3) to create the\r | |
256 | certificate list.\r | |
257 | \r | |
258 | If you want to create the certificate list based on the CA certificates\r | |
259 | in your local host, p11-kit will be a good choice. Here is the command to\r | |
260 | create the list:\r | |
261 | \r | |
262 | p11-kit extract --format=edk2-cacerts --filter=ca-anchors \\r | |
263 | --overwrite --purpose=server-auth <certdb>\r | |
264 | \r | |
265 | If you only want to import one certificate, efisiglist is the tool for you:\r | |
266 | \r | |
267 | efisiglist -a <cert file> -o <certdb>\r | |
268 | \r | |
269 | Please note that the certificate has to be in the DER format.\r | |
270 | \r | |
271 | You can also append a certificate to the existing list with the following\r | |
272 | command:\r | |
273 | \r | |
274 | efisiglist -i <old certdb> -a <cert file> -o <new certdb>\r | |
275 | \r | |
276 | NOTE: You may need the patch to make efisiglist generate the correct header.\r | |
277 | (https://github.com/rhboot/pesign/pull/40)\r | |
278 | \r | |
279 | * Besides the trusted certificates, it's also possible to configure the trusted\r | |
280 | cipher suites for HTTPS through another fw_cfg entry: etc/edk2/https/ciphers.\r | |
281 | \r | |
d3180516 GL |
282 | OVMF expects a binary UINT16 array which comprises the cipher suites HEX\r |
283 | IDs(*4). If the cipher suite list is given, OVMF will choose the cipher\r | |
284 | suite from the intersection of the given list and the built-in cipher\r | |
285 | suites. Otherwise, OVMF just chooses whatever proper cipher suites from the\r | |
286 | built-in ones.\r | |
287 | \r | |
3f3daf89 LE |
288 | - Using QEMU 5.2 or later, QEMU can expose the ordered list of permitted TLS\r |
289 | cipher suites from the host side to OVMF:\r | |
290 | \r | |
291 | -object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \\r | |
292 | -fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0\r | |
293 | \r | |
294 | (Refer to the QEMU manual and to\r | |
295 | <https://gnutls.org/manual/html_node/Priority-Strings.html> for more\r | |
296 | information on the "priority" property.)\r | |
297 | \r | |
298 | - Using QEMU 5.1 or earlier, the array has to be passed from a file:\r | |
299 | \r | |
300 | -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>\r | |
301 | \r | |
302 | whose contents can be generated with the following script, for example:\r | |
d3180516 GL |
303 | \r |
304 | export LC_ALL=C\r | |
305 | openssl ciphers -V \\r | |
306 | | sed -r -n \\r | |
307 | -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \\r | |
308 | | xargs -r -- printf -- '%b' > ciphers.bin\r | |
309 | \r | |
310 | This script creates ciphers.bin that contains all the cipher suite IDs\r | |
311 | supported by openssl according to the local host configuration.\r | |
312 | \r | |
313 | You may want to enable only a limited set of cipher suites. Then, you\r | |
314 | should check the validity of your list first:\r | |
315 | \r | |
316 | openssl ciphers -V <cipher list>\r | |
317 | \r | |
318 | If all the cipher suites in your list map to the proper HEX IDs, go ahead\r | |
319 | to modify the script and execute it:\r | |
320 | \r | |
321 | export LC_ALL=C\r | |
322 | openssl ciphers -V <cipher list> \\r | |
323 | | sed -r -n \\r | |
324 | -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \\r | |
325 | | xargs -r -- printf -- '%b' > ciphers.bin\r | |
326 | \r | |
d3180516 GL |
327 | (*1) See "31.4.1 Signature Database" in UEFI specification 2.7 errata A.\r |
328 | (*2) p11-kit: https://github.com/p11-glue/p11-kit/\r | |
329 | (*3) efisiglist: https://github.com/rhboot/pesign/blob/master/src/efisiglist.c\r | |
330 | (*4) https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table\r | |
d3180516 | 331 | \r |
e58e5bcd JJ |
332 | === OVMF Flash Layout ===\r |
333 | \r | |
f78c8bf2 LE |
334 | Like all current IA32/X64 system designs, OVMF's firmware device (rom/flash)\r |
335 | appears in QEMU's physical address space just below 4GB (0x100000000).\r | |
e58e5bcd | 336 | \r |
f78c8bf2 LE |
337 | OVMF supports building a 1MB, 2MB or 4MB flash image (see the DSC files for the\r |
338 | FD_SIZE_1MB, FD_SIZE_2MB, FD_SIZE_4MB build defines). The base address for the\r | |
339 | 1MB image in QEMU physical memory is 0xfff00000. The base address for the 2MB\r | |
340 | image is 0xffe00000. The base address for the 4MB image is 0xffc00000.\r | |
341 | \r | |
342 | Using the 1MB or 2MB image, the layout of the firmware device in memory looks\r | |
343 | like:\r | |
e58e5bcd JJ |
344 | \r |
345 | +--------------------------------------- 4GB (0x100000000)\r | |
346 | | VTF0 (16-bit reset code) and OVMF SEC\r | |
f78c8bf2 | 347 | | (SECFV, 208KB/0x34000)\r |
e58e5bcd JJ |
348 | +--------------------------------------- varies based on flash size\r |
349 | |\r | |
350 | | Compressed main firmware image\r | |
351 | | (FVMAIN_COMPACT)\r | |
352 | |\r | |
353 | +--------------------------------------- base + 0x20000\r | |
354 | | Fault-tolerant write (FTW)\r | |
355 | | Spare blocks (64KB/0x10000)\r | |
356 | +--------------------------------------- base + 0x10000\r | |
357 | | FTW Work block (4KB/0x1000)\r | |
358 | +--------------------------------------- base + 0x0f000\r | |
359 | | Event log area (4KB/0x1000)\r | |
360 | +--------------------------------------- base + 0x0e000\r | |
361 | | Non-volatile variable storage\r | |
362 | | area (56KB/0xe000)\r | |
363 | +--------------------------------------- base address\r | |
364 | \r | |
f78c8bf2 LE |
365 | Using the 4MB image, the layout of the firmware device in memory looks like:\r |
366 | \r | |
367 | +--------------------------------------- base + 0x400000 (4GB/0x100000000)\r | |
368 | | VTF0 (16-bit reset code) and OVMF SEC\r | |
369 | | (SECFV, 208KB/0x34000)\r | |
370 | +--------------------------------------- base + 0x3cc000\r | |
371 | |\r | |
372 | | Compressed main firmware image\r | |
373 | | (FVMAIN_COMPACT, 3360KB/0x348000)\r | |
374 | |\r | |
375 | +--------------------------------------- base + 0x84000\r | |
376 | | Fault-tolerant write (FTW)\r | |
377 | | Spare blocks (264KB/0x42000)\r | |
378 | +--------------------------------------- base + 0x42000\r | |
379 | | FTW Work block (4KB/0x1000)\r | |
380 | +--------------------------------------- base + 0x41000\r | |
381 | | Event log area (4KB/0x1000)\r | |
382 | +--------------------------------------- base + 0x40000\r | |
383 | | Non-volatile variable storage\r | |
384 | | area (256KB/0x40000)\r | |
385 | +--------------------------------------- base address (0xffc00000)\r | |
e58e5bcd JJ |
386 | \r |
387 | The code in SECFV locates FVMAIN_COMPACT, and decompresses the\r | |
388 | main firmware (MAINFV) into RAM memory at address 0x800000. The\r | |
389 | remaining OVMF firmware then uses this decompressed firmware\r | |
390 | volume image.\r | |
391 | \r | |
90803342 LE |
392 | === UEFI Windows 7 & Windows 2008 Server ===\r |
393 | \r | |
394 | * One of the '-vga std' and '-vga qxl' QEMU options should be used.\r | |
395 | * Only one video mode, 1024x768x32, is supported at OS runtime.\r | |
396 | * The '-vga qxl' QEMU option is recommended. After booting the installed\r | |
397 | guest OS, select the video card in Device Manager, and upgrade its driver\r | |
398 | to the QXL XDDM one. Download location:\r | |
399 | <http://www.spice-space.org/download.html>, Guest | Windows binaries.\r | |
400 | This enables further resolutions at OS runtime, and provides S3\r | |
401 | (suspend/resume) capability.\r |