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
OvmfPkg/SMBIOS: Reuse handles supplied by underlying VM

The SMBIOS specification requires some structure types to
contain reference fields to other structures' handles. When
InstallAllStructures() rebuilds the SMBIOS tables by traversing
an existing source table, the use of SMBIOS_HANDLE_PI_RESERVED
causes automatically generated, arbitrary handle numbers to be
assigned to each cloned structure. This causes all reference
handle fields to become invalid.

This patch modifies InstallAllStructures() to reuse the original
handle numbers supplied by the underlying VM, preserving the
correctness of any included handle references.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Anthony PERARD <anthony.perard@citrix.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15541 6f19259b-4bc3-4df7-8a09-765794883524
OvmfPkg/SMBIOS: Add QEMU support to OVMF SMBIOS driver

Locate QEMU SMBIOS data in fw_cfg and install it via the
SMBIOS protocol.

Starting with qemu-2.1, on pc/x86 machines of type >= 2.1, full
SMBIOS tables are generated and inserted into fw_cfg (i.e., no
per-field patching of locally generated structures is required).

Aside from new code to extract a SMBIOS blob from fw_cfg, this
patch utilizes the pre-existing infrastructure (already used by
Xen) to handle final SMBIOS table creation.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo <somlo@cmu.edu>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15542 6f19259b-4bc3-4df7-8a09-765794883524