| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
GraphicsConsoleDxe will assert in case the resolution is too small.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some platforms (such as SBSA-QEMU on recent builds of the emulator) only
tolerate misaligned accesses to normal memory, and raise alignment
faults on such accesses to device memory, which is the default for PCIe
MMIO BARs.
When emulating a PCIe graphics controller, the framebuffer is typically
exposed via a MMIO BAR, while the disposition of the region is closer to
memory (no side effects on reads or writes, except for the changing
picture on the screen; direct random access to any pixel in the image).
In order to permit the use of such controllers on platforms that only
tolerate these types of accesses for normal memory, it is necessary to
remap the memory. Use the DXE services to set the desired capabilities
and attributes.
Hide this behavior under a feature PCD so only platforms that really
need it can enable it. (OVMF on x86 has no need for this)
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
The guest os which depends on vbeshim for video support is -- according
to the comments -- Windows 2008 R2. Which went EOL in January 2020,
more than four years ago.
Time to retire VbeShim. RIP.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
OvmfPkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Per my bisection: nasm broke the parsing of the "--" end-of-options
delimiter in commit 55568c1193df ("nasm: scan the command line twice",
2016-10-03), part of the nasm-2.13 release. The parsing remains broken in
at least nasm-2.15.03. The (invalid) error message is: "more than one
input file specified". I've filed the following ticket for upstream nasm
(and ndisasm): <https://bugzilla.nasm.us/show_bug.cgi?id=3392829>.
Since the delimiter is not necessary in practice (due to $STEM being
"VbeShim", i.e., not starting with a hyphen), simply remove the delimiter.
Tested by enabling DEBUG in "VbeShim.asm", running the script, building
OVMF, booting Windows 7, and checking the firmware log (debug console).
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3876
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add VgaInb() helper function to read vga registers. With that in place
fix the unblanking. We need to put the ATT_ADDRESS_REGISTER flip flop
into a known state, which is done by reading the
INPUT_STATUS_1_REGISTER. Reading the INPUT_STATUS_1_REGISTER only works
when the device is in color mode, so make sure that bit (0x01) is set in
MISC_OUTPUT_REGISTER.
Currently the mode setting works more by luck because
ATT_ADDRESS_REGISTER flip flop happens to be in the state we need.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ensure that the PixelInformation field of the
EFI_GRAPHICS_OUTPUT_MODE_INFORMATION structure is zeroed out in
EFI_GRAPHICS_OUTPUT_PROTOCOL.QueryMode() and
EFI_GRAPHICS_OUTPUT_PROTOCOL.SetMode() when PixelFormat is
PixelBlueGreenRedReserved8BitPerColor.
According to UEFI 2.9 Section 12.9, PixelInformation field of the
EFI_GRAPHICS_OUTPUT_MODE_INFORMATION structure is valid only if
PixelFormat is PixelBitMask. This means that firmware is not required
to fill out the PixelInformation field for other PixelFormat types,
which implies that the QemuVideoDxe implementation is technically
correct.
However, not zeroing out those fields will leak the contents of the
memory returned by the memory allocator, so it is better to explicitly
set them to zero.
In addition, the SCT test suite relies on PixelInformation always
having a consistent value, which causes failures.
Signed-off-by: Dimitrije Pavlov <Dimitrije.Pavlov@arm.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
|
|
|
|
|
| |
Those old windows versions which need the vbeshim hack
will not run on microvm anyway.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3875
Reverts changes automatically applied by Uncrustify in commit
ac0a286.
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rebecca Cran <rebecca@bsdio.com>
Cc: Peter Grehan <grehan@freebsd.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Check whenever an EDID blob is present. In case it is get the display
resolution from it. Unless PcdVideoResolutionSource indicates the
display resolution has been set already, update
PcdVideoHorizontalResolution and PcdVideoVerticalResolution accordingly.
Also add the resolution to the mode list.
This will make OVMF boot up with the display resolution configured by
QEMU, which is 1280x800 by default. The resolution can be set using the
xres and yres properties. Here is an example for FullHD:
qemu-system-x86_64 -device VGA,xres=1920,yres=1080
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3778
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1749250
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
|
|
|
|
|
|
|
|
|
| |
Add helper function to add a video mode to the list of modes.
Move code. Minor debug logging tweaks, no other functional
change.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
|
|
|
|
|
|
|
|
| |
All video modes in the list are 32-bit,
so drop the useless ColorDepth field.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
|
|
|
|
|
|
|
|
|
| |
struct QEMU_VIDEO_MODE_DATA has all the data needed to set the video
mode, there is no need to take the extra indirection and use
struct QEMU_VIDEO_BOCHS_MODES.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
|
|
|
|
|
|
|
|
|
|
|
|
| |
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737
Apply uncrustify changes to .c/.h files in the OvmfPkg package
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Andrew Fish <afish@apple.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3760
Update all use of ', OPTIONAL' to ' OPTIONAL,' for function params.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Andrew Fish <afish@apple.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Generated mechanically with:
find OvmfPkg -type f -exec sed -i -e 's/EFI_D_/DEBUG_/g' {} \;
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@arm.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200429215327.606467-1-rebecca@bsdio.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In edk2 commit 333f32ec23dd, QemuVideoDxe gained support for QEMU's
"secondary-vga" device model (originally introduced in QEMU commit
63e3e24db2e9).
In QEMU commit 765c94290863, the "bochs-display" device was introduced,
which would work with QemuVideoDxe out of the box, reusing the
"secondary-vga" logic.
Support for both models has been broken since edk2 commit 662bd0da7fd7.
Said patch ended up requiring VGA IO Ports -- i.e., at least one of
EFI_PCI_IO_ATTRIBUTE_VGA_IO and EFI_PCI_IO_ATTRIBUTE_VGA_IO_16 -- even if
the device wasn't actually VGA compatible.
Restrict the IO Ports requirement to VGA compatible devices.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Marc W Chen <marc.w.chen@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Fixes: 662bd0da7fd77e4d2cf9ef4a78015af5cad7d9db
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2555
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200224171741.7494-1-lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix various typos in comments and documentation.
When "VbeShim.asm" is modified, we have to re-run "VbeShim.sh"
to update "VbeShim.h".
The string modified by this patch is only used when the DEBUG
macro (at the top of the file) is commented out. Since the
string is not referenced, NASM eliminates it, resulting in
the same byte array content in "VbeShim.h".
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Antoine Coeur <coeur@gmx.fr>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20200207010831.9046-58-philmd@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Query the supported attributes firstly, then bitwise AND (&) both VGA_IO
and VGA_IO_16. Since the supported attributes should only have one of
VGA_IO or VGA_IO_16 set, the result of bitwise AND (&) is either VGA_IO
or IO_16. Then the result can be passed to PciIo->Attributes() to set the
attributes.
Device driver should consider both since the mReserveVgaAliases in
PciBusDxe driver is default FALSE(implies that device driver can only set
VGA_IO_16 to PCI_ROOT_BRIDGE), and Platform code may not return
EFI_RESERVE_VGA_IO_ALIAS in GetPlatformPolicy of PciPlatformProtocol to
make mReserveVgaAliases become TRUE(implies that device driver can only
set VGA_IO to PCI_ROOT_BRIDGE), Currently OvmfPkg doesn't have problem
due to it has hard code value for PCI_ROOT_BRIDGE's attributes field, so
an IO access by PciIoProtocol will be successed due to
RootBridgeIoCheckParameter of PciRootBridgeIo.c will always get pass
result for legacy IO access.
Usually the attributes field of PCI_ROOT_BRIDGE should be 0, in that case
it will have issue since the VGA_IO may not be able to be enabled, then
IO access by PciIoProtocol will be failed, hence the QemuVideoDxe driver
will not work fine.
Signed-off-by: Marc Chen <marc.w.chen@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1880
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190606074237.81492-1-marc.w.chen@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Update the QemuVideoDxe driver to not depend on the
OptionRomPkg to support moving OptionRomPkg to the
edk2-platforms repository.
The only dependency on the OptionRomPkg is the use of
PcdDriverSupportedEfiVersion to set the version value in the
EFI Driver Supported EFI Version Protocol.
Quoting the UEFI-2.8 spec, "This protocol is required for EFI
drivers that are *on* PCI and other plug in cards" (emphasis ours).
However, QemuVideoDxe is always part of the OVMF platform firmware,
and is never read by PciBusDxe from the PCI ROM BAR of QEMU's
emulated graphics cards.
Since this protocol does not apply to QEMU environment, remove
both the PCD and the installation of the EFI Driver Supported EFI
Version Protocol.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The real mode interrupt vector table, which we modify for the sake of
Windows 7, starts at address 0, which happens to be the representation of
null pointers on all edk2 architectures. A null pointer may never undergo
pointer arithmetic, and RH covscan justifiedly reports:
> Error: CPPCHECK_WARNING (CWE-682):
> edk2-89910a39dcfd/OvmfPkg/QemuVideoDxe/VbeShim.c:105:
> error[nullPointerArithmetic]: Pointer addition with NULL pointer.
> # 103| //
> # 104| Segment0Pages = 1;
> # 105|-> Int0x10 = (IVT_ENTRY *)(UINTN)Segment0 + 0x10;
> # 106| Segment0AllocationStatus = gBS->AllocatePages (
> # 107| AllocateAddress,
Fix this by calculating the EFI_PHYSICAL_ADDRESS of IVT entry 0x10 first,
and by casting the address to the right type second.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1710
Issue: scan-1002.txt
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://bugzilla.tianocore.org/show_bug.cgi?id=1373
Replace BSD 2-Clause License with BSD+Patent License. This change is
based on the following emails:
https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html
https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html
RFCs with detailed process for the license change:
V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html
V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html
V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BAR | std vga | vmsvga
---------------------------------
0 | Framebuffer | I/O space
1 | Reserved | Framebuffer
2 | MMIO | FIFO
- We cannot recognize VMW SVGA as BOCHS because that would confuse the
IsQxl setting in QemuVideoControllerDriverStart(),
- We cannot recognize VMW SVGA as BOCHS_MMIO because BAR2 on VMW SVGA is
not the BOCHS MMIO BAR (we can only use port IO).
Therefore the list of reasons for which we should introduce
QEMU_VIDEO_VMWARE_SVGA should name three reasons:
(1) Get framebuffer from correct PCI BAR
(2) Prevent using BAR2 for MMIO
(3) Prevent mis-recognizing VMW SVGA as QXL
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin <yuchenlin@synology.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 05a5379458725234de8a05780fcb5da2c12680e4.
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. However, we reverted the initialization of VMWare SVGA device,
we don't need such unaligned I/O.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin <yuchenlin@synology.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
(cherry picked from commit 438ada5aa5a1174940795678c2dae07cde8f3869)
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit c137d95081690d4877fbeb5f1856972e84ac32f2.
The VMWare SVGA model now -- since commit 104bd1dc70 in QEMU --
falls back to stdvga (that is, Bochs) if we don't setup VMWare SVGA
FIFO.
To simplify QemuVideoDxe, we don't intend to implement the VMWare SVGA
FIFO setup feature. It means our current VMW SVGA driver code is
basically dead. To simplify the problem, we will replace the old
VMWare SVGA driver to Bochs interface. It should work on all QEMU
version.
The first step for using Bochs interface is to revert old driver.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin <yuchenlin@synology.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
(cherry picked from commit 98856a724c2acdc0094220d4de615a557dad0f88)
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit b2959e9f1a57279506ca46d56bc424fd7fa6b62a.
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. However, we will revert the initialization of VMWare SVGA
device later, we don't need such unaligned I/O.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin <yuchenlin@synology.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
(cherry picked from commit e038bde2679bbd200086c25ab43090ad3b8b25a3)
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit e038bde2679bbd200086c25ab43090ad3b8b25a3, reapplying
b2959e9f1a57279506ca46d56bc424fd7fa6b62a.
Note that the commit now being reverted is technically correct; the only
reason we're reverting it is because it should not have been pushed past
the Soft Feature Freeze for the edk2-stable201811 tag.
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: yuchenlin <yuchenlin@synology.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1319
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: yuchenlin <yuchenlin@synology.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 98856a724c2acdc0094220d4de615a557dad0f88, reapplying
c137d95081690d4877fbeb5f1856972e84ac32f2.
Note that the commit now being reverted is technically correct; the only
reason we're reverting it is because it should not have been pushed past
the Soft Feature Freeze for the edk2-stable201811 tag.
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: yuchenlin <yuchenlin@synology.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1319
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: yuchenlin <yuchenlin@synology.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 438ada5aa5a1174940795678c2dae07cde8f3869,
reapplying 05a5379458725234de8a05780fcb5da2c12680e4.
Note that the commit now being reverted is technically correct; the only
reason we're reverting it is because it should not have been pushed past
the Soft Feature Freeze for the edk2-stable201811 tag.
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: yuchenlin <yuchenlin@synology.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1319
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: yuchenlin <yuchenlin@synology.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 05a5379458725234de8a05780fcb5da2c12680e4.
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. However, we reverted the initialization of VMWare SVGA device,
we don't need such unaligned I/O.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin <yuchenlin@synology.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit c137d95081690d4877fbeb5f1856972e84ac32f2.
The VMWare SVGA model now -- since commit 104bd1dc70 in QEMU --
falls back to stdvga (that is, Bochs) if we don't setup VMWare SVGA
FIFO.
To simplify QemuVideoDxe, we don't intend to implement the VMWare SVGA
FIFO setup feature. It means our current VMW SVGA driver code is
basically dead. To simplify the problem, we will replace the old
VMWare SVGA driver to Bochs interface. It should work on all QEMU
version.
The first step for using Bochs interface is to revert old driver.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin <yuchenlin@synology.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit b2959e9f1a57279506ca46d56bc424fd7fa6b62a.
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. However, we will revert the initialization of VMWare SVGA
device later, we don't need such unaligned I/O.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin <yuchenlin@synology.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Removing rules for Ipf sources file:
* Remove the source file which path with "ipf" and also listed in
[Sources.IPF] section of INF file.
* Remove the source file which listed in [Components.IPF] section
of DSC file and not listed in any other [Components] section.
* Remove the embedded Ipf code for MDE_CPU_IPF.
Removing rules for Inf file:
* Remove IPF from VALID_ARCHITECTURES comments.
* Remove DXE_SAL_DRIVER from LIBRARY_CLASS in [Defines] section.
* Remove the INF which only listed in [Components.IPF] section in DSC.
* Remove statements from [BuildOptions] that provide IPF specific flags.
* Remove any IPF sepcific sections.
Removing rules for Dec file:
* Remove [Includes.IPF] section from Dec.
Removing rules for Dsc file:
* Remove IPF from SUPPORTED_ARCHITECTURES in [Defines] section of DSC.
* Remove any IPF specific sections.
* Remove statements from [BuildOptions] that provide IPF specific flags.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen <chen.a.chen@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
|
|
|
|
|
|
| |
This makes QemuVideo bind to the secondary-vga device.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
|
|
|
|
|
|
|
|
|
|
| |
Then check for PCI_CLASS_DISPLAY_VGA using the new field.
This allows to enable/disable non-vga display classes per
card entry.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Guests do the same, because the framebuffer is mapped somewhere, which
obviously works with page granularity only.
When not rounding up to full page size we get messages like this one
(linux kernel):
efifb: framebuffer at 0x80000000, using 1876k, total 1875k
^^^^^ ^^^^^
Also sysfb is confused and throws an error:
sysfb: VRAM smaller than advertised
Cc: Phil Dennis-Jordan <phil@philjordan.eu>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: fix coding style]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
According to the UEFI spec, EFI_GRAPHICS_OUTPUT_PROTOCOL.Blt() is supposed
to catch an invalid BltOperation, and report it with
EFI_INVALID_PARAMETER.
Remove the assertion from QemuVideoGraphicsOutputBlt() that prevents this
from working in NOOPT and DEBUG builds.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Rocky <xingrong.ni@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Reported-by: Rocky <xingrong.ni@intel.com>
Analyzed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=897
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Today's implementation forgot to clear the screen to black in
SetMode(). It causes SCT SetMode() test fails.
The patch adds the clear screen operation in SetMode() to fix
the SCT failure.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The header file is manually generated with "VbeShim.sh" (from the IA32
assembly code in "VbeShim.asm"), to be included by "VbeShim.c".
"VbeShim.c" is linked into the driver only for the IA32 and X64
architectures: while the InstallVbeShim() function that "VbeShim.c"
defines is declared commonly in "Qemu.h", the call in the also common
"Driver.c" source file depends on the MDE_CPU_IA32 / MDE_CPU_X64
preprocessor macros.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Phil Dennis-Jordan <phil@philjordan.eu>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The header file declares the UnalignedIoWrite32() and UnalignedIoRead32()
functions. The functions are called from VmwareSvgaWrite() and
VmwareSvgaRead() in the common "Driver.c" source file. The
UnalignedIo*32() functions are defined with inline assembly, C-language
compiler intrinsics, or as ASSERT(FALSE), in distinct C files, dependent
on architecture and toolchain.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Phil Dennis-Jordan <phil@philjordan.eu>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Among many other things, "Qemu.h" declares the
QemuVideoGraphicsOutputConstructor() and
QemuVideoGraphicsOutputDestructor() functions, which are defined in
"Gop.c", and called from "Driver.c".
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Phil Dennis-Jordan <phil@philjordan.eu>
Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.intel.com
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it easier to insert future source files. No functional changes.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Phil Dennis-Jordan <phil@philjordan.eu>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 db27e9f3d8f0 ("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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This clarifies the purpose of the local variable in InstallVbeShim().
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
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 84a75f70e903 (SVN 16890) and
05a537945872.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In addition to the QXL, Cirrus, etc. VGA adapters, Qemu also implements
a basic version of VMWare's SVGA display device. Drivers for this
device exist for some guest OSes which do not support Qemu's other
display adapters, so supporting it in OVMF is useful in conjunction
with those OSes.
This change adds support for the SVGA device's framebuffer to
QemuVideoDxe's graphics output protocol implementation, based on
VMWare's documentation. The most basic initialisation, framebuffer
layout query, and mode setting operations are implemented.
The device relies on port-based 32-bit I/O, unfortunately on misaligned
addresses. This limits the driver's support to the x86 family of
platforms.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.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 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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://bugzilla.tianocore.org/show_bug.cgi?id=339
The patch removes the assumption in QemuVideoDxe driver that it
wrongly assumes the frame buffer configure size is the same in
different video modes.
The assumption is true in old FrameBufferBltLib but is false in
new implementation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
|
|
|
|
|
|
|
| |
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
|