QemuVideoDxe driver will link VBE SHIM into page 0. If NULL pointer
detection is enabled, this driver will fail to load. NULL pointer detection
bypassing code is added to prevent such problem during boot.
Please note that Windows 7 will try to access VBE SHIM during boot if it's
installed, and then cause boot failure. This can be fixed by setting BIT7
of PcdNullPointerDetectionPropertyMask to disable NULL pointer detection
after EndOfDxe. As far as we know, there's no other OSs has such issue.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ayellet Wolman <ayellet.wolman@intel.com>
Suggested-by: Ayellet Wolman <ayellet.wolman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
In commit db27e9f3d8 ("OvmfPkg/LegacyRegion: Support legacy region
manipulation of Q35", 2016-03-15), Ray extended the
OvmfPkg/Csm/CsmSupportLib PAM register manipulation to Q35. However, we
missed that the same should be done to the QemuVideoDxe VBE Shim as well.
The omission has caused no problems in practice on Q35, because QEMU has
let us write to the ROM area, regardless of the PAM1 setting, all this
time. This has now changed with recent QEMU commit 208fa0e43645 ("pc: make
'pc.rom' readonly when machine has PCI enabled", 2017-07-28). The QEMU
commit exposes the OVMF bug when Windows 7 is started on Q35, using QEMU
2.10 -- the VBE Shim is no longer put in place and Windows 7 cannot find
it.
To remedy this, assign the "Pam1Address" local variable a PciLib address
that matches the board type (i440fx vs. q35).
Regarding the PcdLib dependency: QemuVideoDxe already uses PcdLib, both
directly (see "PcdDriverSupportedEfiVersion") and indirectly (e.g. via the
DxePciLibI440FxQ35 PciLib instance). Add PcdLib to [LibraryClasses] for
completeness.
Cc: Aleksei Kovura <alex3kov@zoho.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Ref: https://bugs.launchpad.net/qemu/+bug/1715700
Reported-by: Aleksei Kovura <alex3kov@zoho.com>
Special-thanks-to: Gerd Hoffmann <kraxel@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Aleksei Kovura <alex3kov@zoho.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Now that we have dropped QemuVideoDxe from all QEMU targeted builds
under ArmVirtPkg, we can revert the ARM specific changes to it.
This partially reverts commits 84a75f70e9 (SVN 16890) and
05a5379458.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The VMWare SVGA display device implemented by Qemu (-vga vmware) uses
an I/O-type BAR which is laid out such that some register offsets are
not aligned to the read/write width with which they are expected to be
accessed. (The register value port has an offset of 1 and requires
32 bit wide read/write access.)
The EFI_PCI_IO_PROTOCOL's Io.Read/Io.Write functions do not support
such unaligned I/O.
Before a driver for this device can be added to QemuVideoDxe, helper
functions for unaligned I/O are therefore required. This adds the
functions UnalignedIoWrite32 and UnalignedIoRead32, based on IoLib's
IoWrite32 and IoRead32, for the Ia32 and X64 architectures. Port I/O
requires inline assembly, so implementations are provided for the GCC,
ICC, and Microsoft compiler families. Such I/O is not possible on other
architectures, a dummy (ASSERT()ing) implementation is therefore
provided to satisfy the linker.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
The only feature not portable to ArmVirtualizationQemu is the VBE shim;
make that dependent on Ia32 / X64.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Olivier Martin <Olivier.martin@arm.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@16890 6f19259b-4bc3-4df7-8a09-765794883524
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
Move to a table-driven hardware detection. Add a table with PCI IDs,
card name and variant enum. Use the table for hardware detection and
initialization. Rename Cirrus-specific data and code to carry "cirrus"
in the name.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@13967 6f19259b-4bc3-4df7-8a09-765794883524
This driver provides a UEFI Graphics Output Protocol (GOP) driver
for the QEMU Cirrus VGA hardware. It enables 24-bit color,
and uses the standard 32-bit GOP pixel format whenever possible.
git-svn-id: https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@11524 6f19259b-4bc3-4df7-8a09-765794883524
Jian J Wang
Laszlo Ersek
Ard Biesheuvel
Phil Dennis-Jordan
Ruiyu Ni
jljusten
ydong10
lzeng14