2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
=== OVMF OVERVIEW ===
|
|
|
|
|
|
|
|
The Open Virtual Machine Firmware (OVMF) project aims
|
|
|
|
to support firmware for Virtual Machines using the edk2
|
|
|
|
code base. More information can be found at:
|
|
|
|
|
2010-02-22 19:17:13 +01:00
|
|
|
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
=== STATUS ===
|
|
|
|
|
|
|
|
Current capabilities:
|
|
|
|
* IA32 and X64 architectures
|
2012-12-17 03:12:11 +01:00
|
|
|
* QEMU (0.10.0 or later)
|
2009-05-27 23:10:18 +02:00
|
|
|
- Video, keyboard, IDE, CD-ROM, serial
|
|
|
|
- Runs UEFI shell
|
2010-07-26 20:07:19 +02:00
|
|
|
- Optional NIC support. Requires QEMU (0.12.2 or later)
|
2012-12-17 03:12:11 +01:00
|
|
|
* UEFI Linux boots
|
|
|
|
* UEFI Windows 8 boots
|
OvmfPkg: QemuVideoDxe: Int10h stub for Windows 7 & 2008 (stdvga, QXL)
The Windows 2008 R2 SP1 (and Windows 7) UEFI guest's default video driver
dereferences the real mode Int10h vector, loads the pointed-to handler
code, and executes what it thinks to be VGA BIOS services in an internal
real-mode emulator. Consequently, video mode switching doesn't work in
Windows 2008 R2 SP1 when it runs on the pure UEFI build of OVMF, making
the guest uninstallable.
This patch adds a VGABIOS "shim" to QemuVideoDxe. For the first stdvga or
QXL card bound, an extremely stripped down VGABIOS imitation is installed
in the C segment. It provides a real implementation for the few services
that are in fact necessary for the win2k8r2sp1 UEFI guest, plus some fakes
that the guest invokes but whose effect is not important.
The C segment is not present in the UEFI memory map prepared by OVMF. We
never add memory space that would cover it (either in PEI, in the form of
memory resource descriptor HOBs, or in DXE, via gDS->AddMemorySpace()).
This way the handler body is invisible to all non-buggy UEFI guests, and
the rest of edk2.
The Int10h real-mode IVT entry is covered with a Boot Services Code page,
making that too unaccessible to the rest of edk2. (Thus UEFI guest OSes
different from the Windows 2008 family can reclaim the page. The Windows
2008 family accesses the page at zero regardless of the allocation type.)
The patch is the result of collaboration:
Initial proof of concept IVT entry installation and handler skeleton (in
NASM) by Jordan Justen.
Service tracing and implementation, data collection/analysis, and C coding
by yours truly.
Last minute changes by Gerd Hoffmann:
- Use OEM mode number (0xf1) instead of standard 800x600 mode (0x143). The
resolution of the OEM mode (0xf1) is not standardized; the guest can't
expect anything from it in advance.
- Use 1024x768 rather than 800x600 for more convenience in the Windows
2008 R2 SP1 guest during OS installation, and after normal boot until
the QXL XDDM guest driver is installed.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15540 6f19259b-4bc3-4df7-8a09-765794883524
2014-05-20 18:33:00 +02:00
|
|
|
* UEFI Windows 7 & Windows 2008 Server boot (see important notes below!)
|
2009-05-27 23:10:18 +02:00
|
|
|
|
|
|
|
=== FUTURE PLANS ===
|
|
|
|
|
|
|
|
* Test/Stabilize UEFI Self-Certification Tests (SCT) results
|
|
|
|
|
2009-05-28 20:02:25 +02:00
|
|
|
=== BUILDING OVMF ===
|
|
|
|
|
|
|
|
Pre-requisites:
|
|
|
|
* Build environment capable of build the edk2 MdeModulePkg.
|
2011-01-09 04:50:21 +01:00
|
|
|
* A properly configured ASL compiler:
|
|
|
|
- Intel ASL compiler: Available from http://www.acpica.org
|
|
|
|
- Microsoft ASL compiler: Available from http://www.acpi.info
|
2014-08-19 01:04:00 +02:00
|
|
|
* NASM: http://www.nasm.us/
|
2009-05-28 20:02:25 +02:00
|
|
|
|
|
|
|
Update Conf/target.txt ACTIVE_PLATFORM for OVMF:
|
|
|
|
PEI arch DXE arch UEFI interfaces
|
|
|
|
* OvmfPkg/OvmfPkgIa32.dsc IA32 IA32 IA32
|
|
|
|
* OvmfPkg/OvmfPkgIa32X64.dsc IA32 X64 X64
|
|
|
|
* OvmfPkg/OvmfPkgX64.dsc X64 X64 X64
|
|
|
|
|
2009-07-15 01:32:44 +02:00
|
|
|
Update Conf/target.txt TARGET_ARCH based on the .dsc file:
|
|
|
|
TARGET_ARCH
|
|
|
|
* OvmfPkg/OvmfPkgIa32.dsc IA32
|
|
|
|
* OvmfPkg/OvmfPkgIa32X64.dsc IA32 X64
|
|
|
|
* OvmfPkg/OvmfPkgX64.dsc X64
|
|
|
|
|
|
|
|
Following the edk2 build process, you will find the OVMF binaries
|
|
|
|
under the $WORKSPACE/Build/*/*/FV directory. The actual path will
|
|
|
|
depend on how your build is configured. You can expect to find
|
|
|
|
these binary outputs:
|
2010-07-26 20:07:19 +02:00
|
|
|
* OVMF.FD
|
2011-01-09 04:50:21 +01:00
|
|
|
- Please note! This filename has changed. Older releases used OVMF.Fv.
|
2012-05-28 08:37:32 +02:00
|
|
|
* OvmfVideo.rom
|
2013-04-03 20:20:57 +02:00
|
|
|
- This file is not built separately any longer, starting with svn r13520.
|
2009-07-15 01:32:44 +02:00
|
|
|
|
|
|
|
More information on building OVMF can be found at:
|
2010-02-22 19:17:13 +01:00
|
|
|
|
|
|
|
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=How_to_build_OVMF
|
2009-05-28 20:02:25 +02:00
|
|
|
|
|
|
|
=== RUNNING OVMF on QEMU ===
|
|
|
|
|
2014-01-03 20:19:14 +01:00
|
|
|
* QEMU 0.12.2 or later is required.
|
2009-05-28 20:02:25 +02:00
|
|
|
* Be sure to use qemu-system-x86_64, if you are using and X64 firmware.
|
|
|
|
(qemu-system-x86_64 works for the IA32 firmware as well, of course.)
|
2014-01-03 20:19:14 +01:00
|
|
|
* Use OVMF for QEMU firmware (3 options available)
|
|
|
|
- Option 1: QEMU 1.6 or newer; Use QEMU -pflash parameter
|
|
|
|
* QEMU/OVMF will use emulated flash, and fully support UEFI variables
|
|
|
|
* Run qemu with: -pflash path/to/OVMF.fd
|
OvmfPkg: disable stale fork of SecureBootConfigDxe
OvmfPkg forked SecureBootConfigDxe from SecurityPkg in SVN r13635 (git
commit 8c71ec8f). Since then, the original (in
"SecurityPkg/VariableAuthenticated/SecureBootConfigDxe") has diverged
significantly.
The initial diff between the original and the fork, when the fork was made
(ie. at SVN r13635), reads as follows:
> diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig.vfr OvmfPkg/SecureBootConfigDxe/SecureBootConfig.vfr
> --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig.vfr 2014-09-30 23:35:28.598067147 +0200
> +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfig.vfr 2014-08-09 02:40:35.824851626 +0200
> @@ -51,7 +51,7 @@
> questionid = KEY_SECURE_BOOT_ENABLE,
> prompt = STRING_TOKEN(STR_SECURE_BOOT_PROMPT),
> help = STRING_TOKEN(STR_SECURE_BOOT_HELP),
> - flags = INTERACTIVE | RESET_REQUIRED,
> + flags = INTERACTIVE,
> endcheckbox;
> endif;
>
> @@ -158,7 +158,7 @@
> questionid = KEY_SECURE_BOOT_DELETE_PK,
> prompt = STRING_TOKEN(STR_DELETE_PK),
> help = STRING_TOKEN(STR_DELETE_PK_HELP),
> - flags = INTERACTIVE | RESET_REQUIRED,
> + flags = INTERACTIVE,
> endcheckbox;
> endif;
> endform;
> diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf OvmfPkg/SecureBootConfigDxe/SecureBootConfigDxe.inf
> --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf 2014-09-30 23:35:28.598067147 +0200
> +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfigDxe.inf 2014-09-30 23:35:28.577067027 +0200
> @@ -1,5 +1,8 @@
> ## @file
> -# Component name for SecureBoot configuration module.
> +# Component name for SecureBoot configuration module for OVMF.
> +#
> +# Need custom SecureBootConfigDxe for OVMF that does not force
> +# resets after PK changes since OVMF doesn't have persistent variables
> #
> # Copyright (c) 2011 - 2012, Intel Corporation. All rights reserved.<BR>
> # This program and the accompanying materials
> diff -ur SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c OvmfPkg/SecureBootConfigDxe/SecureBootConfigImpl.c
> --- SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c 2014-09-30 23:35:28.599067153 +0200
> +++ OvmfPkg/SecureBootConfigDxe/SecureBootConfigImpl.c 2014-09-30 23:35:28.578067033 +0200
> @@ -2559,7 +2559,7 @@
> NULL
> );
> } else {
> - *ActionRequest = EFI_BROWSER_ACTION_REQUEST_RESET;
> + *ActionRequest = EFI_BROWSER_ACTION_REQUEST_SUBMIT;
> }
> break;
The commit message is not overly verbose:
OvmfPkg: Add custom SecureBootConfigDxe that doesn't reset
We don't force a platform reset for OVMF when PK is changed in custom
mode setup.
But the INF file hunk is telling:
Need custom SecureBootConfigDxe for OVMF that does not force resets
after PK changes since OVMF doesn't have persistent variables
We do have persistent variables now. Let's disable the (now obsolete)
OvmfPkg fork, and revert to the (well maintained) SecurityPkg-provided
config driver.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Gary Lin <glin@suse.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16191 6f19259b-4bc3-4df7-8a09-765794883524
2014-10-02 10:08:05 +02:00
|
|
|
* Note that this option is required for running SecureBoot-enabled builds
|
|
|
|
(-D SECURE_BOOT_ENABLE).
|
2014-01-03 20:19:14 +01:00
|
|
|
- Option 2: Use QEMU -bios parameter
|
|
|
|
* Note that UEFI variables will be partially emulated, and non-volatile
|
|
|
|
variables may lose their contents after a reboot
|
|
|
|
* Run qemu with: -bios path/to/OVMF.fd
|
|
|
|
- Option 3: Use QEMU -L parameter
|
|
|
|
* Note that UEFI variables will be partially emulated, and non-volatile
|
|
|
|
variables may lose their contents after a reboot
|
|
|
|
* Either copy, rename or symlink OVMF.fd => bios.bin
|
|
|
|
* Use the QEMU -L parameter to specify the directory where the bios.bin
|
|
|
|
file is located.
|
2009-05-28 20:02:25 +02:00
|
|
|
* The EFI shell is built into OVMF builds at this time, so it should
|
|
|
|
run automatically if a UEFI boot application is not found on the
|
|
|
|
removable media.
|
2010-12-31 08:55:23 +01:00
|
|
|
* On Linux, newer version of QEMU may enable KVM feature, and this might
|
|
|
|
cause OVMF to fail to boot. The QEMU '-no-kvm' may allow OVMF to boot.
|
2013-05-15 10:09:29 +02:00
|
|
|
* Capturing OVMF debug messages on qemu:
|
|
|
|
- The default OVMF build writes debug messages to IO port 0x402. The
|
|
|
|
following qemu command line options save them in the file called
|
|
|
|
debug.log: '-debugcon file:debug.log -global isa-debugcon.iobase=0x402'.
|
|
|
|
- It is possible to revert to the original behavior, when debug messages were
|
|
|
|
written to the emulated serial port (potentially intermixing OVMF debug
|
|
|
|
output with UEFI serial console output). For this the
|
|
|
|
'-D DEBUG_ON_SERIAL_PORT' option has to be passed to the build command (see
|
|
|
|
the next section), and in order to capture the serial output qemu needs to
|
|
|
|
be started with eg. '-serial file:serial.log'.
|
|
|
|
- Debug messages fall into several categories. Logged vs. suppressed
|
|
|
|
categories are controlled at OVMF build time by the
|
|
|
|
'gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel' bitmask (an UINT32
|
|
|
|
value) in the selected .dsc file. Individual bits of this bitmask are
|
|
|
|
defined in <MdePkg/Include/Library/DebugLib.h>. One non-default bit (with
|
|
|
|
some performance impact) that is frequently set for debugging is 0x00400000
|
|
|
|
(DEBUG_VERBOSE).
|
|
|
|
- The RELEASE build target ('-b RELEASE' build option, see below) disables
|
|
|
|
all debug messages. The default build target is DEBUG.
|
2010-12-31 08:55:11 +01:00
|
|
|
|
|
|
|
=== Build Scripts ===
|
|
|
|
|
2011-01-09 04:50:21 +01:00
|
|
|
On systems with the bash shell you can use OvmfPkg/build.sh to simplify
|
|
|
|
building and running OVMF.
|
2010-12-31 08:55:11 +01:00
|
|
|
|
|
|
|
So, for example, to build + run OVMF X64:
|
2011-01-09 04:50:21 +01:00
|
|
|
$ OvmfPkg/build.sh -a X64
|
|
|
|
$ OvmfPkg/build.sh -a X64 qemu
|
2010-12-31 08:55:11 +01:00
|
|
|
|
|
|
|
And to run a 64-bit UEFI bootable ISO image:
|
2011-01-09 04:50:21 +01:00
|
|
|
$ OvmfPkg/build.sh -a X64 qemu -cdrom /path/to/disk-image.iso
|
|
|
|
|
2013-05-15 10:09:29 +02:00
|
|
|
To build a 32-bit OVMF without debug messages using GCC 4.5:
|
2011-01-09 04:50:21 +01:00
|
|
|
$ OvmfPkg/build.sh -a IA32 -b RELEASE -t GCC45
|
2010-12-31 08:55:11 +01:00
|
|
|
|
2010-12-31 08:55:23 +01:00
|
|
|
=== Network Support ===
|
|
|
|
|
2013-06-14 09:41:13 +02:00
|
|
|
OVMF provides a UEFI network stack by default. Its lowest level driver is the
|
|
|
|
NIC driver, higher levels are generic. In order to make DHCP, PXE Boot, and eg.
|
|
|
|
socket test utilities from the StdLib edk2 package work, (1) qemu has to be
|
|
|
|
configured to emulate a NIC, (2) a matching UEFI NIC driver must be available
|
|
|
|
when OVMF boots.
|
2013-05-15 20:20:39 +02:00
|
|
|
|
|
|
|
(If a NIC is configured for the virtual machine, and -- dependent on boot order
|
|
|
|
-- PXE booting is attempted, but no DHCP server responds to OVMF's DHCP
|
|
|
|
DISCOVER message at startup, the boot process may take approx. 3 seconds
|
|
|
|
longer.)
|
|
|
|
|
|
|
|
* For each NIC emulated by qemu, a GPLv2 licensed UEFI driver is available from
|
|
|
|
the iPXE project. The qemu source distribution, starting with version 1.5,
|
|
|
|
contains prebuilt binaries of these drivers (and of course allows one to
|
2013-06-14 09:41:13 +02:00
|
|
|
rebuild them from source as well). This is the recommended set of drivers.
|
2013-05-15 20:20:39 +02:00
|
|
|
|
|
|
|
* Use the qemu -netdev and -device options, or the legacy -net option, to
|
|
|
|
enable NIC support: <http://wiki.qemu.org/Documentation/Networking>.
|
|
|
|
|
|
|
|
* For a qemu >= 1.5 binary running *without* any "-M machine" option where
|
|
|
|
"machine" would identify a < qemu-1.5 configuration (for example: "-M
|
2013-06-14 09:41:13 +02:00
|
|
|
pc-i440fx-1.4" or "-M pc-0.13"), the iPXE drivers are automatically available
|
|
|
|
to and configured for OVMF in the default qemu installation.
|
2013-05-15 20:20:39 +02:00
|
|
|
|
|
|
|
* For a qemu binary in [0.13, 1.5), or a qemu >= 1.5 binary with an "-M
|
|
|
|
machine" option where "machine" selects a < qemu-1.5 configuration:
|
|
|
|
|
|
|
|
- download a >= 1.5.0-rc1 source tarball from <http://wiki.qemu.org/Download>,
|
|
|
|
|
2013-06-14 09:41:13 +02:00
|
|
|
- extract the following iPXE driver files from the tarball and install them
|
|
|
|
in a location that is accessible to qemu processes (this may depend on your
|
2013-05-15 20:20:39 +02:00
|
|
|
SELinux configuration, for example):
|
|
|
|
|
|
|
|
qemu-VERSION/pc-bios/efi-e1000.rom
|
|
|
|
qemu-VERSION/pc-bios/efi-ne2k_pci.rom
|
|
|
|
qemu-VERSION/pc-bios/efi-pcnet.rom
|
|
|
|
qemu-VERSION/pc-bios/efi-rtl8139.rom
|
|
|
|
qemu-VERSION/pc-bios/efi-virtio.rom
|
|
|
|
|
|
|
|
- extend the NIC's -device option on the qemu command line with a matching
|
|
|
|
"romfile=" optarg:
|
|
|
|
|
|
|
|
-device e1000,...,romfile=/full/path/to/efi-e1000.rom
|
|
|
|
-device ne2k_pci,...,romfile=/full/path/to/efi-ne2k_pci.rom
|
|
|
|
-device pcnet,...,romfile=/full/path/to/efi-pcnet.rom
|
|
|
|
-device rtl8139,...,romfile=/full/path/to/efi-rtl8139.rom
|
|
|
|
-device virtio-net-pci,...,romfile=/full/path/to/efi-virtio.rom
|
|
|
|
|
2013-06-14 09:41:13 +02:00
|
|
|
* Independently of the iPXE NIC drivers, the default OVMF build provides a
|
|
|
|
basic virtio-net driver, located in OvmfPkg/VirtioNetDxe.
|
|
|
|
|
|
|
|
* Also independently of the iPXE NIC drivers, Intel's proprietary E1000 NIC
|
|
|
|
driver (PROEFI) can be embedded in the OVMF image at build time:
|
2013-05-15 20:20:39 +02:00
|
|
|
|
|
|
|
- Download UEFI drivers for the e1000 NIC
|
|
|
|
- http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17515&lang=eng
|
|
|
|
- Install the drivers into a directory called Intel3.5 in your WORKSPACE.
|
|
|
|
|
|
|
|
- Include the driver in OVMF during the build:
|
|
|
|
- Add "-D E1000_ENABLE -D FD_SIZE_2MB" to your build command,
|
|
|
|
- For example: "build -D E1000_ENABLE -D FD_SIZE_2MB".
|
2010-12-31 08:55:23 +01:00
|
|
|
|
2013-06-14 09:41:13 +02:00
|
|
|
* When a matching iPXE driver is configured for a NIC as described above, it
|
|
|
|
takes priority over other drivers that could possibly drive the card too:
|
|
|
|
|
|
|
|
| e1000 ne2k_pci pcnet rtl8139 virtio-net-pci
|
|
|
|
-------------+------------------------------------------------
|
|
|
|
iPXE | x x x x x
|
|
|
|
VirtioNetDxe | x
|
|
|
|
Intel PROEFI | x
|
|
|
|
|
2013-11-12 19:34:28 +01:00
|
|
|
=== OVMF Flash Layout ===
|
|
|
|
|
|
|
|
Like all current IA32/X64 system designs, OVMF's firmware
|
|
|
|
device (rom/flash) appears in QEMU's physical address space
|
|
|
|
just below 4GB (0x100000000).
|
|
|
|
|
|
|
|
The layout of the firmware device in memory looks like:
|
|
|
|
|
|
|
|
+--------------------------------------- 4GB (0x100000000)
|
|
|
|
| VTF0 (16-bit reset code) and OVMF SEC
|
|
|
|
| (SECFV)
|
|
|
|
+--------------------------------------- varies based on flash size
|
|
|
|
|
|
|
|
|
| Compressed main firmware image
|
|
|
|
| (FVMAIN_COMPACT)
|
|
|
|
|
|
|
|
|
+--------------------------------------- base + 0x20000
|
|
|
|
| Fault-tolerant write (FTW)
|
|
|
|
| Spare blocks (64KB/0x10000)
|
|
|
|
+--------------------------------------- base + 0x10000
|
|
|
|
| FTW Work block (4KB/0x1000)
|
|
|
|
+--------------------------------------- base + 0x0f000
|
|
|
|
| Event log area (4KB/0x1000)
|
|
|
|
+--------------------------------------- base + 0x0e000
|
|
|
|
| Non-volatile variable storage
|
|
|
|
| area (56KB/0xe000)
|
|
|
|
+--------------------------------------- base address
|
|
|
|
|
|
|
|
OVMF supports building a 1MB or a 2MB flash image. The base address for
|
|
|
|
a 1MB image in QEMU physical memory is 0xfff00000. The base address for
|
|
|
|
a 2MB image is 0xffe00000.
|
|
|
|
|
|
|
|
The code in SECFV locates FVMAIN_COMPACT, and decompresses the
|
|
|
|
main firmware (MAINFV) into RAM memory at address 0x800000. The
|
|
|
|
remaining OVMF firmware then uses this decompressed firmware
|
|
|
|
volume image.
|
|
|
|
|
2012-07-31 19:54:18 +02:00
|
|
|
=== UNIXGCC Debug ===
|
|
|
|
|
|
|
|
If you build with the UNIXGCC toolchain, then debugging will be disabled
|
|
|
|
due to larger image sizes being produced by the UNIXGCC toolchain. The
|
|
|
|
first choice recommendation is to use GCC44 or newer instead.
|
|
|
|
|
|
|
|
If you must use UNIXGCC, then you can override the build options for
|
|
|
|
particular libraries and modules in the .dsc to re-enable debugging
|
|
|
|
selectively. For example:
|
|
|
|
[Components]
|
|
|
|
OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf {
|
|
|
|
<BuildOptions>
|
|
|
|
GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG
|
|
|
|
}
|
|
|
|
IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf {
|
|
|
|
<BuildOptions>
|
|
|
|
GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG
|
|
|
|
}
|
|
|
|
|
OvmfPkg: QemuVideoDxe: Int10h stub for Windows 7 & 2008 (stdvga, QXL)
The Windows 2008 R2 SP1 (and Windows 7) UEFI guest's default video driver
dereferences the real mode Int10h vector, loads the pointed-to handler
code, and executes what it thinks to be VGA BIOS services in an internal
real-mode emulator. Consequently, video mode switching doesn't work in
Windows 2008 R2 SP1 when it runs on the pure UEFI build of OVMF, making
the guest uninstallable.
This patch adds a VGABIOS "shim" to QemuVideoDxe. For the first stdvga or
QXL card bound, an extremely stripped down VGABIOS imitation is installed
in the C segment. It provides a real implementation for the few services
that are in fact necessary for the win2k8r2sp1 UEFI guest, plus some fakes
that the guest invokes but whose effect is not important.
The C segment is not present in the UEFI memory map prepared by OVMF. We
never add memory space that would cover it (either in PEI, in the form of
memory resource descriptor HOBs, or in DXE, via gDS->AddMemorySpace()).
This way the handler body is invisible to all non-buggy UEFI guests, and
the rest of edk2.
The Int10h real-mode IVT entry is covered with a Boot Services Code page,
making that too unaccessible to the rest of edk2. (Thus UEFI guest OSes
different from the Windows 2008 family can reclaim the page. The Windows
2008 family accesses the page at zero regardless of the allocation type.)
The patch is the result of collaboration:
Initial proof of concept IVT entry installation and handler skeleton (in
NASM) by Jordan Justen.
Service tracing and implementation, data collection/analysis, and C coding
by yours truly.
Last minute changes by Gerd Hoffmann:
- Use OEM mode number (0xf1) instead of standard 800x600 mode (0x143). The
resolution of the OEM mode (0xf1) is not standardized; the guest can't
expect anything from it in advance.
- Use 1024x768 rather than 800x600 for more convenience in the Windows
2008 R2 SP1 guest during OS installation, and after normal boot until
the QXL XDDM guest driver is installed.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15540 6f19259b-4bc3-4df7-8a09-765794883524
2014-05-20 18:33:00 +02:00
|
|
|
=== UEFI Windows 7 & Windows 2008 Server ===
|
|
|
|
|
|
|
|
* One of the '-vga std' and '-vga qxl' QEMU options should be used.
|
|
|
|
* Only one video mode, 1024x768x32, is supported at OS runtime.
|
|
|
|
* The '-vga qxl' QEMU option is recommended. After booting the installed
|
|
|
|
guest OS, select the video card in Device Manager, and upgrade its driver
|
|
|
|
to the QXL XDDM one. Download location:
|
|
|
|
<http://www.spice-space.org/download.html>, Guest | Windows binaries.
|
|
|
|
This enables further resolutions at OS runtime, and provides S3
|
|
|
|
(suspend/resume) capability.
|