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.5: 119 $ OvmfPkg/build.sh -a IA32 -b RELEASE -t GCC45 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 (PROEFI) can be embedded in the OVMF image at build time: 228 229 - Download UEFI drivers for the e1000 NIC 230 - http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17515&lang=eng 231 - Install the drivers into a directory called Intel3.5 in your WORKSPACE. 232 233 - Include the driver in OVMF during the build: 234 - Add "-D E1000_ENABLE" to your build command, 235 - For example: "build -D E1000_ENABLE". 236 237 * When a matching iPXE driver is configured for a NIC as described above, it 238 takes priority over other drivers that could possibly drive the card too: 239 240 | e1000 ne2k_pci pcnet rtl8139 virtio-net-pci 241 -------------+------------------------------------------------ 242 iPXE | x x x x x 243 VirtioNetDxe | x 244 Intel PROEFI | x 245 246 === OVMF Flash Layout === 247 248 Like all current IA32/X64 system designs, OVMF's firmware 249 device (rom/flash) appears in QEMU's physical address space 250 just below 4GB (0x100000000). 251 252 The layout of the firmware device in memory looks like: 253 254 +--------------------------------------- 4GB (0x100000000) 255 | VTF0 (16-bit reset code) and OVMF SEC 256 | (SECFV) 257 +--------------------------------------- varies based on flash size 258 | 259 | Compressed main firmware image 260 | (FVMAIN_COMPACT) 261 | 262 +--------------------------------------- base + 0x20000 263 | Fault-tolerant write (FTW) 264 | Spare blocks (64KB/0x10000) 265 +--------------------------------------- base + 0x10000 266 | FTW Work block (4KB/0x1000) 267 +--------------------------------------- base + 0x0f000 268 | Event log area (4KB/0x1000) 269 +--------------------------------------- base + 0x0e000 270 | Non-volatile variable storage 271 | area (56KB/0xe000) 272 +--------------------------------------- base address 273 274 OVMF supports building a 1MB or a 2MB flash image. The base address for 275 a 1MB image in QEMU physical memory is 0xfff00000. The base address for 276 a 2MB image is 0xffe00000. 277 278 The code in SECFV locates FVMAIN_COMPACT, and decompresses the 279 main firmware (MAINFV) into RAM memory at address 0x800000. The 280 remaining OVMF firmware then uses this decompressed firmware 281 volume image. 282 283 === UNIXGCC Debug === 284 285 If you build with the UNIXGCC toolchain, then debugging will be disabled 286 due to larger image sizes being produced by the UNIXGCC toolchain. The 287 first choice recommendation is to use GCC44 or newer instead. 288 289 If you must use UNIXGCC, then you can override the build options for 290 particular libraries and modules in the .dsc to re-enable debugging 291 selectively. For example: 292 [Components] 293 OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf { 294 <BuildOptions> 295 GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG 296 } 297 MdeModulePkg/Universal/BdsDxe/BdsDxe.inf { 298 <BuildOptions> 299 GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG 300 } 301 302 === UEFI Windows 7 & Windows 2008 Server === 303 304 * One of the '-vga std' and '-vga qxl' QEMU options should be used. 305 * Only one video mode, 1024x768x32, is supported at OS runtime. 306 * The '-vga qxl' QEMU option is recommended. After booting the installed 307 guest OS, select the video card in Device Manager, and upgrade its driver 308 to the QXL XDDM one. Download location: 309 <http://www.spice-space.org/download.html>, Guest | Windows binaries. 310 This enables further resolutions at OS runtime, and provides S3 311 (suspend/resume) capability. 312
