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