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