to support firmware for Virtual Machines using the edk2\r
code base. More information can be found at:\r
\r
- https://edk2.tianocore.org/OVMF.html\r
+http://www.tianocore.org/ovmf/\r
\r
=== STATUS ===\r
\r
-Current status: Alpha\r
-\r
Current capabilities:\r
* IA32 and X64 architectures\r
-* QEMU (0.9.1 or later)\r
+* QEMU (0.10.0 or later)\r
- Video, keyboard, IDE, CD-ROM, serial\r
- Runs UEFI shell\r
-* UEFI Linux has booted (but is not stable)\r
+ - Optional NIC support. Requires QEMU (0.12.2 or later)\r
+* UEFI Linux boots\r
+* UEFI Windows 8 boots\r
+* UEFI Windows 7 & Windows 2008 Server boot (see important notes below!)\r
\r
=== FUTURE PLANS ===\r
\r
-* Stabilize UEFI Linux boot\r
* Test/Stabilize UEFI Self-Certification Tests (SCT) results\r
\r
+=== BUILDING OVMF ===\r
+\r
+Pre-requisites:\r
+* Build environment capable of build the edk2 MdeModulePkg.\r
+* A properly configured ASL compiler:\r
+ - Intel ASL compiler: Available from http://www.acpica.org\r
+ - Microsoft ASL compiler: Available from http://www.acpi.info\r
+* NASM: http://www.nasm.us/\r
+\r
+Update Conf/target.txt ACTIVE_PLATFORM for OVMF:\r
+ PEI arch DXE arch UEFI interfaces\r
+* OvmfPkg/OvmfPkgIa32.dsc IA32 IA32 IA32\r
+* OvmfPkg/OvmfPkgIa32X64.dsc IA32 X64 X64\r
+* OvmfPkg/OvmfPkgX64.dsc X64 X64 X64\r
+\r
+Update Conf/target.txt TARGET_ARCH based on the .dsc file:\r
+ TARGET_ARCH\r
+* OvmfPkg/OvmfPkgIa32.dsc IA32\r
+* OvmfPkg/OvmfPkgIa32X64.dsc IA32 X64\r
+* OvmfPkg/OvmfPkgX64.dsc X64\r
+\r
+Following the edk2 build process, you will find the OVMF binaries\r
+under the $WORKSPACE/Build/*/*/FV directory. The actual path will\r
+depend on how your build is configured. You can expect to find\r
+these binary outputs:\r
+* OVMF.FD\r
+ - Please note! This filename has changed. Older releases used OVMF.Fv.\r
+* OvmfVideo.rom\r
+ - This file is not built separately any longer, starting with svn r13520.\r
+\r
+More information on building OVMF can be found at:\r
+\r
+https://github.com/tianocore/tianocore.github.io/wiki/How%20to%20build%20OVMF\r
+\r
+=== RUNNING OVMF on QEMU ===\r
+\r
+* QEMU 0.12.2 or later is required.\r
+* Be sure to use qemu-system-x86_64, if you are using and X64 firmware.\r
+ (qemu-system-x86_64 works for the IA32 firmware as well, of course.)\r
+* Use OVMF for QEMU firmware (3 options available)\r
+ - Option 1: QEMU 1.6 or newer; Use QEMU -pflash parameter\r
+ * QEMU/OVMF will use emulated flash, and fully support UEFI variables\r
+ * Run qemu with: -pflash path/to/OVMF.fd\r
+ * Note that this option is required for running SecureBoot-enabled builds\r
+ (-D SECURE_BOOT_ENABLE).\r
+ - Option 2: Use QEMU -bios parameter\r
+ * Note that UEFI variables will be partially emulated, and non-volatile\r
+ variables may lose their contents after a reboot\r
+ * Run qemu with: -bios path/to/OVMF.fd\r
+ - Option 3: Use QEMU -L parameter\r
+ * Note that UEFI variables will be partially emulated, and non-volatile\r
+ variables may lose their contents after a reboot\r
+ * Either copy, rename or symlink OVMF.fd => bios.bin\r
+ * Use the QEMU -L parameter to specify the directory where the bios.bin\r
+ file is located.\r
+* The EFI shell is built into OVMF builds at this time, so it should\r
+ run automatically if a UEFI boot application is not found on the\r
+ removable media.\r
+* On Linux, newer version of QEMU may enable KVM feature, and this might\r
+ cause OVMF to fail to boot. The QEMU '-no-kvm' may allow OVMF to boot.\r
+* Capturing OVMF debug messages on qemu:\r
+ - The default OVMF build writes debug messages to IO port 0x402. The\r
+ following qemu command line options save them in the file called\r
+ debug.log: '-debugcon file:debug.log -global isa-debugcon.iobase=0x402'.\r
+ - It is possible to revert to the original behavior, when debug messages were\r
+ written to the emulated serial port (potentially intermixing OVMF debug\r
+ output with UEFI serial console output). For this the\r
+ '-D DEBUG_ON_SERIAL_PORT' option has to be passed to the build command (see\r
+ the next section), and in order to capture the serial output qemu needs to\r
+ be started with eg. '-serial file:serial.log'.\r
+ - Debug messages fall into several categories. Logged vs. suppressed\r
+ categories are controlled at OVMF build time by the\r
+ 'gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel' bitmask (an UINT32\r
+ value) in the selected .dsc file. Individual bits of this bitmask are\r
+ defined in <MdePkg/Include/Library/DebugLib.h>. One non-default bit (with\r
+ some performance impact) that is frequently set for debugging is 0x00400000\r
+ (DEBUG_VERBOSE).\r
+ - The RELEASE build target ('-b RELEASE' build option, see below) disables\r
+ all debug messages. The default build target is DEBUG.\r
+\r
+=== Build Scripts ===\r
+\r
+On systems with the bash shell you can use OvmfPkg/build.sh to simplify\r
+building and running OVMF.\r
+\r
+So, for example, to build + run OVMF X64:\r
+$ OvmfPkg/build.sh -a X64\r
+$ OvmfPkg/build.sh -a X64 qemu\r
+\r
+And to run a 64-bit UEFI bootable ISO image:\r
+$ OvmfPkg/build.sh -a X64 qemu -cdrom /path/to/disk-image.iso\r
+\r
+To build a 32-bit OVMF without debug messages using GCC 4.5:\r
+$ OvmfPkg/build.sh -a IA32 -b RELEASE -t GCC45\r
+\r
+=== SMM support ===\r
+\r
+Requirements:\r
+* SMM support requires QEMU 2.5.\r
+* The minimum required QEMU machine type is "pc-q35-2.5".\r
+* SMM with KVM requires Linux 4.4 (host).\r
+\r
+OVMF is capable of utilizing SMM if the underlying QEMU or KVM hypervisor\r
+emulates SMM. SMM is put to use in the S3 suspend and resume infrastructure,\r
+and in the UEFI variable driver stack. The purpose is (virtual) hardware\r
+separation between the runtime guest OS and the firmware (OVMF), with the\r
+intent to make Secure Boot actually secure, by preventing the runtime guest OS\r
+from tampering with the variable store and S3 areas.\r
+\r
+For SMM support, OVMF must be built with the "-D SMM_REQUIRE" option. The\r
+resultant firmware binary will check if QEMU actually provides SMM emulation;\r
+if it doesn't, then OVMF will log an error and trigger an assertion failure\r
+during boot (even in RELEASE builds). Both the naming of the flag (SMM_REQUIRE,\r
+instead of SMM_ENABLE), and this behavior are consistent with the goal\r
+described above: this is supposed to be a security feature, and fallbacks are\r
+not allowed. Similarly, a pflash-backed variable store is a requirement.\r
+\r
+QEMU should be started with the options listed below (in addition to any other\r
+guest-specific flags). The command line should be gradually composed from the\r
+hints below. '\' is used to extend the command line to multiple lines, and '^'\r
+can be used on Windows.\r
+\r
+* QEMU binary and options specific to 32-bit guests:\r
+\r
+ $ qemu-system-i386 -cpu coreduo,-nx \\r
+\r
+ or\r
+\r
+ $ qemu-system-x86_64 -cpu <MODEL>,-lm,-nx \\r
+\r
+* QEMU binary for running 64-bit guests (no particular options):\r
+\r
+ $ qemu-system-x86_64 \\r
+\r
+* Flags common to all SMM scenarios (only the Q35 machine type is supported):\r
+\r
+ -machine q35,smm=on,accel=(tcg|kvm) \\r
+ -m ... \\r
+ -smp ... \\r
+ -global driver=cfi.pflash01,property=secure,value=on \\r
+ -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on \\r
+ -drive if=pflash,format=raw,unit=1,file=copy_of_OVMF_VARS.fd \\r
+\r
+* In order to disable S3, add:\r
+\r
+ -global ICH9-LPC.disable_s3=1 \\r
+\r
+=== Network Support ===\r
+\r
+OVMF provides a UEFI network stack by default. Its lowest level driver is the\r
+NIC driver, higher levels are generic. In order to make DHCP, PXE Boot, and eg.\r
+socket test utilities from the StdLib edk2 package work, (1) qemu has to be\r
+configured to emulate a NIC, (2) a matching UEFI NIC driver must be available\r
+when OVMF boots.\r
+\r
+(If a NIC is configured for the virtual machine, and -- dependent on boot order\r
+-- PXE booting is attempted, but no DHCP server responds to OVMF's DHCP\r
+DISCOVER message at startup, the boot process may take approx. 3 seconds\r
+longer.)\r
+\r
+* For each NIC emulated by qemu, a GPLv2 licensed UEFI driver is available from\r
+ the iPXE project. The qemu source distribution, starting with version 1.5,\r
+ contains prebuilt binaries of these drivers (and of course allows one to\r
+ rebuild them from source as well). This is the recommended set of drivers.\r
+\r
+* Use the qemu -netdev and -device options, or the legacy -net option, to\r
+ enable NIC support: <http://wiki.qemu.org/Documentation/Networking>.\r
+\r
+* For a qemu >= 1.5 binary running *without* any "-M machine" option where\r
+ "machine" would identify a < qemu-1.5 configuration (for example: "-M\r
+ pc-i440fx-1.4" or "-M pc-0.13"), the iPXE drivers are automatically available\r
+ to and configured for OVMF in the default qemu installation.\r
+\r
+* For a qemu binary in [0.13, 1.5), or a qemu >= 1.5 binary with an "-M\r
+ machine" option where "machine" selects a < qemu-1.5 configuration:\r
+\r
+ - download a >= 1.5.0-rc1 source tarball from <http://wiki.qemu.org/Download>,\r
+\r
+ - extract the following iPXE driver files from the tarball and install them\r
+ in a location that is accessible to qemu processes (this may depend on your\r
+ SELinux configuration, for example):\r
+\r
+ qemu-VERSION/pc-bios/efi-e1000.rom\r
+ qemu-VERSION/pc-bios/efi-ne2k_pci.rom\r
+ qemu-VERSION/pc-bios/efi-pcnet.rom\r
+ qemu-VERSION/pc-bios/efi-rtl8139.rom\r
+ qemu-VERSION/pc-bios/efi-virtio.rom\r
+\r
+ - extend the NIC's -device option on the qemu command line with a matching\r
+ "romfile=" optarg:\r
+\r
+ -device e1000,...,romfile=/full/path/to/efi-e1000.rom\r
+ -device ne2k_pci,...,romfile=/full/path/to/efi-ne2k_pci.rom\r
+ -device pcnet,...,romfile=/full/path/to/efi-pcnet.rom\r
+ -device rtl8139,...,romfile=/full/path/to/efi-rtl8139.rom\r
+ -device virtio-net-pci,...,romfile=/full/path/to/efi-virtio.rom\r
+\r
+* Independently of the iPXE NIC drivers, the default OVMF build provides a\r
+ basic virtio-net driver, located in OvmfPkg/VirtioNetDxe.\r
+\r
+* Also independently of the iPXE NIC drivers, Intel's proprietary E1000 NIC\r
+ driver (PROEFI) can be embedded in the OVMF image at build time:\r
+\r
+ - Download UEFI drivers for the e1000 NIC\r
+ - http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17515&lang=eng\r
+ - Install the drivers into a directory called Intel3.5 in your WORKSPACE.\r
+\r
+ - Include the driver in OVMF during the build:\r
+ - Add "-D E1000_ENABLE" to your build command,\r
+ - For example: "build -D E1000_ENABLE".\r
+\r
+* When a matching iPXE driver is configured for a NIC as described above, it\r
+ takes priority over other drivers that could possibly drive the card too:\r
+\r
+ | e1000 ne2k_pci pcnet rtl8139 virtio-net-pci\r
+ -------------+------------------------------------------------\r
+ iPXE | x x x x x\r
+ VirtioNetDxe | x\r
+ Intel PROEFI | x\r
+\r
+=== OVMF Flash Layout ===\r
+\r
+Like all current IA32/X64 system designs, OVMF's firmware\r
+device (rom/flash) appears in QEMU's physical address space\r
+just below 4GB (0x100000000).\r
+\r
+The layout of the firmware device in memory looks like:\r
+\r
++--------------------------------------- 4GB (0x100000000)\r
+| VTF0 (16-bit reset code) and OVMF SEC\r
+| (SECFV)\r
++--------------------------------------- varies based on flash size\r
+|\r
+| Compressed main firmware image\r
+| (FVMAIN_COMPACT)\r
+|\r
++--------------------------------------- base + 0x20000\r
+| Fault-tolerant write (FTW)\r
+| Spare blocks (64KB/0x10000)\r
++--------------------------------------- base + 0x10000\r
+| FTW Work block (4KB/0x1000)\r
++--------------------------------------- base + 0x0f000\r
+| Event log area (4KB/0x1000)\r
++--------------------------------------- base + 0x0e000\r
+| Non-volatile variable storage\r
+| area (56KB/0xe000)\r
++--------------------------------------- base address\r
+\r
+OVMF supports building a 1MB or a 2MB flash image. The base address for\r
+a 1MB image in QEMU physical memory is 0xfff00000. The base address for\r
+a 2MB image is 0xffe00000.\r
+\r
+The code in SECFV locates FVMAIN_COMPACT, and decompresses the\r
+main firmware (MAINFV) into RAM memory at address 0x800000. The\r
+remaining OVMF firmware then uses this decompressed firmware\r
+volume image.\r
+\r
+=== UNIXGCC Debug ===\r
+\r
+If you build with the UNIXGCC toolchain, then debugging will be disabled\r
+due to larger image sizes being produced by the UNIXGCC toolchain. The\r
+first choice recommendation is to use GCC44 or newer instead.\r
+\r
+If you must use UNIXGCC, then you can override the build options for\r
+particular libraries and modules in the .dsc to re-enable debugging\r
+selectively. For example:\r
+ [Components]\r
+ OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf {\r
+ <BuildOptions>\r
+ GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG\r
+ }\r
+ IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf {\r
+ <BuildOptions>\r
+ GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG\r
+ }\r
+\r
+=== UEFI Windows 7 & Windows 2008 Server ===\r
+\r
+* One of the '-vga std' and '-vga qxl' QEMU options should be used.\r
+* Only one video mode, 1024x768x32, is supported at OS runtime.\r
+* The '-vga qxl' QEMU option is recommended. After booting the installed\r
+ guest OS, select the video card in Device Manager, and upgrade its driver\r
+ to the QXL XDDM one. Download location:\r
+ <http://www.spice-space.org/download.html>, Guest | Windows binaries.\r
+ This enables further resolutions at OS runtime, and provides S3\r
+ (suspend/resume) capability.\r