summaryrefslogtreecommitdiff
path: root/OvmfPkg
AgeCommit message (Collapse)AuthorFilesLines
2016-10-16OvmfPkg/QemuVideoDxe: upgrade VERBOSE debug messages to INFOLaszlo Ersek2-3/+3
In commit 5b2291f9567a ("OvmfPkg: QemuVideoDxe uses MdeModulePkg/FrameBufferLib"), QemuVideoDxe was rebased to FrameBufferBltLib. The FrameBufferBltLib instance added in commit b1ca386074bd ("MdeModulePkg: Add FrameBufferBltLib library instance") logs many messages on the VERBOSE level; for example, a normal boot with OVMF can produce 500+ "VideoFill" messages, dependent on the progress bar, when the VERBOSE bit is set in PcdDebugPrintErrorLevel. While FrameBufferBltLib is certainly allowed to log such messages on the VERBOSE level, we should separate those frequent messages from the (infrequent) ones produced by QemuVideoDxe itself. QemuVideoDxe logs VERBOSE messages in three locations (in two functions) at the moment. All of them are infrequent: both QemuVideoBochsModeSetup() and InstallVbeShim() are called from QemuVideoControllerDriverStart(), that is, when a device is bound. Upgrade these messages to INFO level, so that VERBOSE can be disabled in PcdDebugPrintErrorLevel -- perhaps selectively for OvmfPkg/QemuVideoDxe -- without hiding these infrequent messages. 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>
2016-10-16OvmfPkg/QemuVideoDxe: remove useless QEMU_VIDEO_PRIVATE_DATA.LineBufferLaszlo Ersek2-17/+0
This field is (re)allocated in QemuVideoGraphicsOutputSetMode(), released in QemuVideoGraphicsOutputDestructor(), and used for nothing else. Remove it. 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>
2016-10-16OvmfPkg/QemuVideoDxe: remove useless QEMU_VIDEO_PRIVATE_DATA.CurrentModeLaszlo Ersek1-4/+2
This field is never used. 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>
2016-10-16OvmfPkg/QemuVideoDxe: drop QEMU_VIDEO_CIRRUS_MODES.RefreshRateLaszlo Ersek2-9/+8
Thanks to the previous patch, this field is also unnecessary now. Remove it. The patch is best reviewed with "git show --word-diff". 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>
2016-10-16OvmfPkg/QemuVideoDxe: drop useless QEMU_VIDEO_MODE_DATA.RefreshRateLaszlo Ersek2-9/+4
This field is never used beyond assignment and debug-logging. Remove it. 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>
2016-10-12OvmfPkg: add NOOPT build target for source level debuggingBruce Cran3-3/+3
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Yonghong Zhu <yonghong.zhu@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Bruce Cran <bruce.cran@sandisk.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: beautify subject line] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2016-10-12OvmfPkg: Remove unused BltLib referenceRuiyu Ni3-12/+3
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 at redhat.com>
2016-10-12OvmfPkg: QemuVideoDxe uses MdeModulePkg/FrameBufferLibRuiyu Ni3-12/+46
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek at redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com>
2016-10-12OvmfPkg: Include MdeModulePkg/FrameBufferLib in OvmfPkgRuiyu Ni3-0/+3
One of the following patches will change QemuVideoDxe driver to use the new FrameBufferLib. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Laszlo Ersek <lersek at redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com>
2016-09-28OvmfPkg: Use the new LogoDxe driverRuiyu Ni7-22/+7
Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
2016-09-28OvmfPkg/PlatformBds: Do not call BootLogoEnableLogoRuiyu Ni2-8/+7
Prototype of BootLogoEnableLogo will change in following patches, so do not call BootLogoEnableLogo to avoid build failure. Contributed-under: TianoCore Contribution Agreement 1.0 Cc: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
2016-09-22OvmfPkg/VirtioGpuDxe: Fix VS toolchain build failureDandan Bi1-1/+2
V2: add the assert codes. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Cc: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: fix up subject line] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2016-09-13OvmfPkg: Fix typing errors in header filesThomas Huth7-9/+9
Correct some typos in the header files of the OvmfPkg (which have been discovered with the codespell utility). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2016-09-12OvmfPkg: Fix typing errorsThomas Huth9-14/+14
Correct some typos (discovered with the codespell utility) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Thomas Huth <thuth@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-09-12OvmfPkg: convert C files with LF line terminators to CRLFLaszlo Ersek5-805/+805
Run "unix2dos" on the affected files. "git show -b" produces no diff for this patch. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Thomas Huth <thuth@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
2016-09-12OvmfPkg/IndustryStandard: make "Xen/grant_table.h" pure ASCIILaszlo Ersek1-1/+1
The header file includes the UTF-8 encoding (0xE2 0x80 0x99) of the U+2019 (RIGHT SINGLE QUOTATION MARK) code point. Replace it with a simple apostrophe (U+0027, ASCII 0x27). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Thomas Huth <thuth@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Thomas Huth <thuth@redhat.com>
2016-09-08OvmfPkg/QemuBootOrderLib: drop too strict "/HD(" suffix from vblk prefixLaszlo Ersek1-5/+5
Translating QEMU's virtio-block OpenFirmware device path to a UEFI device path prefix was one of the earliest case handled in QemuBootOrderLib. At that time, I terminated the translation output (the UEFI devpath prefix) with a "/HD(" suffix. The intent was for the translation to prefix-match only boot options with HD() device path nodes in them, that is, no auto-generated "device level" boot options. This was motivated by prioritizing specific boot options created by OS installers over auto-generated "device level" options. However, practice has shown that: - OS installers place their installed boot options first in the boot order anyway, - other device types (SATA disks, virtio-scsi disks), where "/HD(" is not appended, work just fine, - requiring "/HD(" actually causes problems: after the OS-installed specific boot option has been lost (or purposely removed), the auto-generated "device level" boot option does the right thing (see the Default Boot Behavior under <http://blog.uncooperative.org/blog/2014/02/06/the-efi-system-partition/>). The "/HD(" requirement causes such boot options to be dropped, which prevents "fallback.efi" from running. Relax the matching by removing the "/HD(" suffix from the translated prefix. Cc: Jordan Justen <jordan.l.justen@intel.com> Fixes: e06a4cd134064590aa1a855ff4b973023279e805 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1373812 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-09-02OvmfPkg: Use MdeModulePkg/ResetSystemRuntimeDxeRuiyu Ni6-6/+6
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
2016-09-02OvmfPkg/ResetSystemLib: Implement ResetPlatformSpecificRuiyu Ni1-1/+22
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
2016-09-01OvmfPkg/VirtioGpuDxe: implement EFI_GRAPHICS_OUTPUT_PROTOCOLLaszlo Ersek4-23/+719
In this patch we replace our "dummy" Graphics Output Protocol interface with the real one. We exploit that EFI_GRAPHICS_OUTPUT_BLT_PIXEL and VirtioGpuFormatB8G8R8X8Unorm have identical representations; this lets us forego any pixel format conversions in the guest. For messaging the VirtIo GPU device, we use the primitives introduced in the previous patch. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-09-01OvmfPkg/VirtioGpuDxe: provide functions for sending VirtIo GPU commandsLaszlo Ersek2-1/+439
In this patch we add a "workhorse" function called VirtioGpuSendCommand(), and implement seven simple RPCs atop, for the command types listed in "OvmfPkg/Include/IndustryStandard/VirtioGpu.h". These functions will be called by our EFI_GRAPHICS_OUTPUT_PROTOCOL implementation. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-09-01OvmfPkg/VirtioGpuDxe: initialize and tear down VirtIo GPU deviceLaszlo Ersek4-1/+311
This patch implements the steps listed in section "3.1.1 Driver Requirements: Device Initialization" of the Virtio V1.0 Committee Spec 04. The VirtIo GPU is brought up in VirtioGpuDriverBindingStart(), and down in VirtioGpuDriverBindingStop(). We also add an ExitBootServices() callback that resets the device. This ensures that the device model abandons any guest memory areas when we transfer control to the guest OS. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-09-01OvmfPkg: include VirtioGpuDxe in the platform DSC/FDF filesLaszlo Ersek6-0/+6
At this stage, the driver builds, and suffices for testing binding and unbinding. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-09-01OvmfPkg/VirtioGpuDxe: introduce with Component Name 2 and Driver BindingLaszlo Ersek3-0/+984
This patch adds the skeleton of the driver: it implements the Component Name 2 Protocol and the Driver Binding Protocol, in accordance with the generic and GOP-specific requirements set forth in the UEFI spec and the Driver Writers' Guide. The basic idea is that VGPU_DEV abstracts the virtio GPU device, while the single VGPU_GOP that we intend to support at this point stands for "head" (aka "scanout") #0. For now, the Virtio Device Protocol is only used for driver binding; no actual virtio operations are done yet. Similarly, we use a "dummy" GOP GUID and protocol structure (a plain UINT8 object) for now, so that GOP-consuming drivers don't look at what we produce just yet. The driver is a bit different from the other virtio device drivers written thus far: - It implements the GetControllerName() member of the Component Name 2 Protocol. (Formatting helpful names is recommended by UEFI.) As a "best effort", we format the PCI BDF into the name (a PCI backend is not guaranteed by VIRTIO_DEVICE_PROTOCOL). It should provide a more friendly experience in the shell and elsewhere. - This driver seeks to support all RemainingDevicePath cases: - NULL: produce all (= one) child handles (= VGPU_GOP heads) at once, - End of Device Path Node: produce no child handles, - specific ACPI ADR Node: check if it's supportable, and produce it (only one specific child controller is supported). This is one of the reasons for separating VGPU_GOP from VGPU_DEV. The driver is a hybrid driver: it produces both child handles (one, to be exact), but also installs a structure (VGPU_DEV) directly on the VirtIo controller handle, using gEfiCallerIdGuid as protocol GUID. This is a trick I've seen elsewhere in edk2 (for example, TerminalDxe), and it is necessary for the following reason: In EFI_COMPONENT_NAME2_PROTOCOL.GetControllerName(), we must be able to "cast down" a VirtIo ControllerHandle to our own private data structure (VGPU_DEV). That's only possible if we install the structure directly on the VirtIo ControllerHandle (thereby rendering the driver a hybrid driver), because a child controller with our GOP implementation on it may not exist / be passed in there. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-09-01OvmfPkg/IndustryStandard: add type definitions for the virtio GPU deviceLaszlo Ersek2-0/+221
The GPU additions to VirtIo 1.0 are a work in progress. Mark the relevant URLs in the source code. Incorporate the absolute minimum from the WIP spec that is necessary for implementing a GOP driver. Add the VIRTIO_SUBSYSTEM_GPU_DEVICE macro to "IndustryStandard/Virtio10.h", since all other such macros (dating back to VirtIo 0.9.5) are part of "IndustryStandard/Virtio095.h". Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-09-01OvmfPkg/PlatformBootManagerLib: relax device class requirement for ConOutLaszlo Ersek1-5/+5
This will add virtio-gpu-pci devices to ConOut automatically. For further benefit, the change also allows OVMF to use the legacy-free / secondary VGA adapter (added in QEMU commit 63e3e24d, "vga: add secondary stdvga variant") as console. ArmVirtPkg's PlatformBootManagerLib already filters with IS_PCI_DISPLAY(); see IsPciDisplay(). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66 Originally-suggested-by: Gerd Hoffmann <kraxel@redhat.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>
2016-09-01OvmfPkg/Virtio10Dxe: don't bind virtio-vgaLaszlo Ersek1-3/+15
Commit 9399f68ae359 ("OvmfPkg: Virtio10Dxe: non-transitional driver for virtio-1.0 PCI devices") created a "competition" between Virtio10Dxe and QemuVideoDxe for virtio-vga devices. The binding order between these drivers is unspecified, and the wrong order effectively breaks commit 94210dc95e9f ("OvmfPkg: QemuVideoDxe: add virtio-vga support"). Thus, never bind virtio-vga in Virtio10Dxe; QemuVideoDxe provides better compatibility for guest OSes that insist on inheriting a linear framebuffer. Users who prefer the VirtIo GPU interface at boot time should specify virtio-gpu-pci, which is exactly virtio-vga, minus the VGA compatibility (such as the framebuffer). Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66 Fixes: 9399f68ae359234b142c293ad1bef75f470ced30 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-09-01OvmfPkg/QemuVideoDxe: don't incorrectly bind virtio-gpu-pciLaszlo Ersek1-0/+3
The PCI (Vendor ID, Device ID) pair (0x1af4, 0x1050) stands for both the virtio-vga and the virtio-gpu-pci device models of QEMU. They differ in two things: - the former has a VGA-compatibility linear framebuffer on top of the latter, - the former has PCI_CLASS_DISPLAY_VGA device class, while the latter has PCI_CLASS_DISPLAY_OTHER. In commit 94210dc95e9f ("OvmfPkg: QemuVideoDxe: add virtio-vga support"), we enabled QemuVideoDxe to drive virtio-vga simply by adding its (Vendor ID, Device ID) pair to gQemuVideoCardList. This change inadvertently allowed QemuVideoDxe to bind virtio-gpu-pci, which it cannot drive though. Restrict QemuVideoDxe to PCI_CLASS_DISPLAY_VGA, in order to exclude virtio-gpu-pci. For the other cards that QemuVideoDxe drives, this makes no difference. (Note that OvmfPkg's PlatformBootManagerLib instance has always only added PCI_CLASS_DISPLAY_VGA devices to ConOut; see DetectAndPreparePlatformPciDevicePath().) Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Ref: https://tianocore.acgmultimedia.com/show_bug.cgi?id=66 Fixes: 94210dc95e9f7c6ff4066a9b35a288e6f1c271bf Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-08-17OvmfPkg: Add MpInitLib reference in DSC files.Jeff Fan3-0/+6
This update is for CpuMpPei&CpuDxe consuming MP Initialize library. Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Michael Kinney <michael.d.kinney@intel.com> Tested-by: Laszlo Ersek <lersek@redhat.com>
2016-08-02OvmfPkg: use StatusCode Router and Handler from MdeModulePkgCinnamon Shia6-12/+30
In the Platform Init v1.4a spec, - Volume 1 "4.7 Status Code Service" defines the EFI_PEI_SERVICES.ReportStatusCode() service, - Volume 1 "6.3.5 Status Code PPI (Optional)" defines the EFI_PEI_PROGRESS_CODE_PPI (equivalent to the above), - Volume 2 "14.2 Status Code Runtime Protocol" defines the EFI_STATUS_CODE_PROTOCOL. These allow PEIMs and DXE (and later) modules to report status codes. Currently OvmfPkg uses modules from under "IntelFrameworkModulePkg/Universal/StatusCode/", which produce the above abstractions (PPI and PROTOCOL) directly, and write the status codes, as they are reported, to the serial port or to a memory buffer. This is called "handling" the status codes. In the Platform Init v1.4a spec, - Volume 3 "7.2.2 Report Status Code Handler PPI" defines EFI_PEI_RSC_HANDLER_PPI, - Volume 3 "7.2.1 Report Status Code Handler Protocol" defines EFI_RSC_HANDLER_PROTOCOL. These allow several PEIMs and runtime DXE drivers to register callbacks for status code handling. MdeModulePkg offers a PEIM under "MdeModulePkg/Universal/ReportStatusCodeRouter/Pei" that produces both EFI_PEI_PROGRESS_CODE_PPI and EFI_PEI_RSC_HANDLER_PPI, and a runtime DXE driver under "MdeModulePkg/Universal/ReportStatusCodeRouter/RuntimeDxe" that produces both EFI_STATUS_CODE_PROTOCOL and EFI_RSC_HANDLER_PROTOCOL. MdeModulePkg also offers status code handler modules under MdeModulePkg/Universal/StatusCodeHandler/ that depend on EFI_PEI_RSC_HANDLER_PPI and EFI_RSC_HANDLER_PROTOCOL, respectively. The StatusCodeHandler modules register themselves with ReportStatusCodeRouter through EFI_PEI_RSC_HANDLER_PPI / EFI_RSC_HANDLER_PROTOCOL. When another module reports a status code through EFI_PEI_PROGRESS_CODE_PPI / EFI_STATUS_CODE_PROTOCOL, it reaches the phase-matching ReportStatusCodeRouter module first, which in turn passes the status code to the pre-registered, phase-matching StatusCodeHandler module. The status code handling in the StatusCodeHandler modules is identical to the one currently provided by the IntelFrameworkModulePkg modules. Replace the IntelFrameworkModulePkg modules with the MdeModulePkg ones, so we can decrease our dependency on IntelFrameworkModulePkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Cinnamon Shia <cinnamon.shia@hpe.com> Suggested-by: Liming Gao <liming.gao@intel.com> Fixes: https://tianocore.acgmultimedia.com/show_bug.cgi?id=63 [jordan.l.justen@intel.com: point out IntelFareworkModulePkg typos] Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [lersek@redhat.com: rewrap to 74 cols; fix IntelFareworkModulePkg typos] Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
2016-07-27OvmfPkg/Sec: Support SECTION2 DXEFV typesThomas Palmer1-3/+13
Support down-stream projects that require large DXEFV sizes greater than 16MB by handling SECTION2 common headers. These are already created by the build tools when necessary. Use IS_SECTION2 and SECTION2_SIZE macros to calculate accurate image sizes when appropriate. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Thomas Palmer <thomas.palmer@hpe.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: fix NB->MB typo in commit message] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2016-07-27OvmfPkg/Sec: Use EFI_COMMON_SECTION_HEADER to avoid castsThomas Palmer1-4/+5
Drop superfluous casts. There is no change in behavior because EFI_FIRMWARE_VOLUME_IMAGE_SECTION is just a typedef of EFI_COMMON_SECTION_HEADER. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Thomas Palmer <thomas.palmer@hpe.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
2016-07-18OvmfPkg/PlatformPei: silence X64 VS2015x86 warningLaszlo Ersek1-1/+1
VS2015x86 reports the following warning for "OvmfPkg/PlatformPei/MemDetect.c": > MemDetect.c(357): error C2220: warning treated as error - no 'object' > file generated > MemDetect.c(357): warning C4244: '=': conversion from 'UINT64' to > 'UINT32', possible loss of data LowerMemorySize is first assigned from GetSystemMemorySizeBelow4gb(), which returns UINT32. Change the type of LowerMemorySize accordingly. 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: Liming Gao <liming.gao@intel.com>
2016-07-18OvmfPkg/PciHostBridgeLib: silence IA32 VS2015x86 warningsLaszlo Ersek1-2/+2
When compiling "OvmfPkg\Library\PciHostBridgeLib\XenSupport.c" for IA32, the VS2015x86 compiler emits the following: > XenSupport.c(41): error C2220: warning treated as error - no 'object' > file generated > XenSupport.c(41): warning C4244: 'function': conversion from 'UINT64' to > 'UINTN', possible loss of data > XenSupport.c(48): warning C4244: 'function': conversion from 'UINT64' to > 'UINTN', possible loss of data > XenSupport.c(49): warning C4244: 'function': conversion from 'UINT64' to > 'UINTN', possible loss of data > XenSupport.c(50): warning C4244: 'function': conversion from 'UINT64' to > 'UINTN', possible loss of data > XenSupport.c(222): warning C4244: 'function': conversion from 'UINT64' > to 'UINTN', possible loss of data > XenSupport.c(241): warning C4244: 'function': conversion from 'UINT64' > to 'UINTN', possible loss of data PciLib functions take UINTN addresses that were encoded with the PCI_LIB_ADDRESS() macro. We carry addresses from the macro invocations to the function calls in two UINT64 variables however. This loses no data, but it alerts VS2015x86. Change the variable types to UINTN. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
2016-07-15OvmfPkg/PlatformPei: program MSR_IA32_FEATURE_CONTROL from fw_cfgLaszlo Ersek4-0/+142
Under certain circumstances, QEMU exposes the "etc/msr_feature_control" fw_cfg file, with a 64-bit little endian value. The firmware is supposed to write this value to MSR_IA32_FEATURE_CONTROL (0x3a), on all processors, on the normal and the S3 resume boot paths. Utilize EFI_PEI_MPSERVICES_PPI to implement this feature. Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Fixes: https://github.com/tianocore/edk2/issues/97 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-07-15OvmfPkg: include UefiCpuPkg/CpuMpPeiLaszlo Ersek6-0/+18
In the next patch we're going to put EFI_PEI_MP_SERVICES_PPI to use. CpuMpPei uses the following PCDs from gUefiCpuPkgTokenSpaceGuid, beyond those already used by CpuDxe: - PcdCpuMicrocodePatchAddress and PcdCpuMicrocodePatchRegionSize: these control whether CpuMpPei performs microcode update. If the region size is zero, then the microcode update is skipped. UefiCpuPkg.dec sets the region size to zero by default, which is appropriate for OVMF. - PcdCpuApLoopMode and PcdCpuApTargetCstate: the former controls how CpuMpPei puts the APs to sleep: 1 -- HLT, 2 -- MWAIT, 3 -- busy wait (with PAUSE). The latter PCD is only relevant if the former PCD is 2 (MWAIT). In order to be consistent with SeaBIOS and with CpuDxe itself, we choose HLT. That's the default set by UefiCpuPkg.dec. Furthermore, although CpuMpPei could consume SecPeiCpuExceptionHandlerLib technically, it is supposed to consume PeiCpuExceptionHandlerLib. See: - http://thread.gmane.org/gmane.comp.bios.edk2.devel/12703 - git commit a81abf161666 ("UefiCpuPkg/ExceptionLib: Import PeiCpuExceptionHandlerLib module"), part of the series linked above. Jeff recommended to resolve CpuExceptionHandlerLib to PeiCpuExceptionHandlerLib for all PEIMs: - http://thread.gmane.org/gmane.comp.bios.edk2.devel/14471/focus=14477 Since at the moment we have no resolution in place that would cover this for PEIMs (from either [LibraryClasses] or [LibraryClasses.common.PEIM]), it's easy to do. Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-07-15OvmfPkg: remove PcdS3AcpiReservedMemoryBase, PcdS3AcpiReservedMemorySizeLaszlo Ersek4-10/+0
No module in OvmfPkg uses these PCDs any longer. The first PCD mentioned is declared by OvmfPkg, so we can remove even the declaration. The second PCD comes from IntelFrameworkModulePkg. The module that consumes PcdS3AcpiReservedMemorySize is called "IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe", and it is built into OVMF. However, AcpiS3SaveDxe consumes the PCD only conditionally: it depends on the feature PCD called PcdFrameworkCompatibilitySupport, which we never enable in OVMF. The 32KB gap that used to be the S3 permanent PEI memory is left unused in MEMFD for now; it never hurts to have a few KB available there, for future features. Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-07-15OvmfPkg/PlatformPei: rebase and resize the permanent PEI memory for S3Laszlo Ersek2-14/+30
Move the permanent PEI memory for the S3 resume boot path to the top of the low RAM (just below TSEG if the SMM driver stack is included in the build). The new size is derived from CpuMpPei's approximate memory demand. Save the base address and the size in new global variables, regardless of the boot path. On the normal boot path, use these variables for covering the area with EfiACPIMemoryNVS type memory. PcdS3AcpiReservedMemoryBase and PcdS3AcpiReservedMemorySize become unused in PlatformPei; remove them. Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-07-15OvmfPkg/PlatformPei: create one memory HOB at S3 resume too, for CpuMpPeiLaszlo Ersek1-1/+23
CpuMpPei will have to place the AP startup vector in memory under 1MB. For this, CpuMpPei borrows memory under 1MB, but it needs a memory resource descriptor HOB to exist there even on the S3 resume path (see the GetWakeupBuffer() function). Produce such a HOB as an exception on the S3 resume path. CpuMpPei is going be dispatched no earlier than PlatformPei, because CpuMpPei has a depex on gEfiPeiMemoryDiscoveredPpiGuid, and PlatformPei calls PublishSystemMemory(). Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-07-13OvmfPkg/PlatformPei: add missing auto variable initializationArd Biesheuvel1-0/+1
The E820EntriesCount variable in XenPublishRamRegions() may be referenced without being initialized on RELEASE builds, since the ASSERT that fires if the call to XenGetE820Map() fails is compiled out in that case. So initialize it to 0. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2016-07-13OvmfPkg: add PciHotPlugInitDxeLaszlo Ersek8-0/+390
After IncompatiblePciDeviceSupportDxe, this is another small driver / protocol implementation that tweaks the behavior of the PCI bus driver in edk2. The protocol is specified in the Platform Init Spec v1.4a, Volume 5, Chapter 12.6 "PCI Hot Plug PCI Initialization Protocol". This implementation steers the PCI bus driver to reserve the following resources ("padding") for each PCI bus, in addition to the BARs of the devices on that PCI bus: - 2MB of 64-bit non-prefetchable MMIO aperture, - 512B of IO port space. The goal is to reserve room for devices hot-plugged at runtime even if the bridge receiving the device is empty at boot time. The 2MB MMIO size is inspired by SeaBIOS. The 512B IO port size is actually only 1/8th of the PCI spec mandated reservation, but the specified size of 4096 has proved wasteful (given the limited size of our IO port space -- see commit bba734ab4c7c). Especially on Q35, where every PCIe root port and downstream port qualifies as a separate bridge (capable of accepting a single device). Test results for this patch: - regardless of our request for 64-bit MMIO reservation, it is downgraded to 32-bit, - although we request 512B alignment for the IO port space reservation, the next upstream bridge rounds it up to 4096B. Cc: "Johnson, Brian J." <bjohnson@sgi.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Andrew Fish <afish@apple.com> Cc: Feng Tian <feng.tian@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Marcel Apfelbaum <marcel@redhat.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Star Zeng <star.zeng@intel.com> Suggested-by: Andrew Fish <afish@apple.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Ruiyu Ni <Ruiyu.ni@intel.com>
2016-07-13OvmfPkg/PlatformBootManagerLib: remove stale FvFile boot optionsLaszlo Ersek2-0/+131
Removes any boot options that point to binaries built into the firmware and have become stale due to any of the following: - DXEFV's base address or size changed (historical), - DXEFV's FvNameGuid changed, - the FILE_GUID of the pointed-to binary changed, - the referenced binary is no longer built into the firmware. For example, multiple such "EFI Internal Shell" boot options can coexist. They technically differ from each other, but may not describe any built-in shell binary exactly. Such options can accumulate in a varstore over time, and while they remain generally bootable (thanks to the efforts of BmGetFileBufferByFvFilePath()), they look bad. Filter out any stale options. This functionality is not added to QemuBootOrderLib, because it is independent from QEMU and fw_cfg. Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@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>
2016-07-13OvmfPkg: add a Name GUID to each Firmware VolumeLaszlo Ersek3-0/+12
The FDF spec mentions the FvNameGuid statement for [FV.xxxx] sections, but the detailed description can be found in Volume 3 of the Platform Init spec (which is at 1.4a currently). Adding an FvNameGuid statement to [FV.xxx] has the following effects (implemented by "BaseTools/Source/C/GenFv/GenFvInternalLib.c"): - The EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset field is set to a nonzero value, pointing after EFI_FIRMWARE_VOLUME_HEADER itself (although not directly, see below). - An EFI_FIRMWARE_VOLUME_EXT_HEADER object is created at the pointed-to address. This object is not followed by any EFI_FIRMWARE_VOLUME_EXT_ENTRY (= extension) entries, so it only specifies the Name GUID for the firmware volume. The EFI_FIRMWARE_VOLUME_EXT_HEADER for each firmware volume can be found in the Build directory as a separate file (20 bytes in size): Build/Ovmf*/*_GCC*/FV/*.ext - The new data consume 48 bytes in the following volumes: SECFV, FVMAIN_COMPACT, DXEFV. They comprise: - 16 padding bytes, - EFI_FFS_FILE_HEADER2 (8 bytes in total: no Name and ExtendedSize fields, and Type=EFI_FV_FILETYPE_FFS_PAD), - EFI_FIRMWARE_VOLUME_EXT_HEADER (20 bytes, see above), - 4 padding bytes. (The initial 16 padding bytes and the EFI_FFS_FILE_HEADER2 structure are the reason why EFI_FIRMWARE_VOLUME_HEADER.ExtHeaderOffset does not point immediately past EFI_FIRMWARE_VOLUME_HEADER.) The sizes of the firmware volumes don't change, only their internal usages grow by 48 bytes. I verified that the statements and calculations in "OvmfPkg/DecomprScratchEnd.fdf.inc" are unaffected and remain valid. - The new data consume 0 bytes in PEIFV. This is because PEIFV has enough internal padding at the moment to accomodate the above structures without a growth in usage. In the future, firmware volumes can be identified by Name GUID (Fv(...) device path nodes), rather than memory location (MemoryMapped(...) device path nodes). This is supposed to improve stability for persistent device paths that refer to FFS files; for example, UEFI boot options. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Suggested-by: Ruiyu Ni <ruiyu.ni@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>
2016-07-08OvmfPkg: Fix typos in commentsGiri P Mudusuru4-9/+9
- accessibla to accessible - exeuction to execution Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Giri P Mudusuru <giri.p.mudusuru@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2016-06-28OvmfPkg: Re-add the Driver Health ManagerBruce Cran6-0/+6
The Driver Health HII menu is not an integral part of the MdeModulePkg BDS driver / UI app. Because we abandoned the IntelFrameworkModulePkg BDS, now we have to get the same functionality explicitly from DriverHealthManagerDxe. Suggested-by: Liming Gao <liming.gao@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Bruce Cran <bruce.cran@gmail.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> [lersek@redhat.com: update commit message] Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2016-06-06OvmfPkg: set SMM stack size to 16KBLaszlo Ersek3-0/+3
The default stack size (from UefiCpuPkg/UefiCpuPkg.dec) is 8KB, which proved too small (i.e., led to stack overflow) across commit range 98c2d9610506^..f85d3ce2efc2^, during certificate enrollment into "db". As the edk2 codebase progresses and OVMF keeps including features, the stack demand constantly fluctuates; double the SMM stack size for good measure. Cc: Jeff Fan <jeff.fan@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Ref: http://thread.gmane.org/gmane.comp.bios.edk2.devel/12864 Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1341733 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-06-02OvmfPkg/PlatformBootManagerLib: Connect the Xen drivers before loading NvVarsGary Lin2-2/+40
When OVMF tried to load the file-based NvVars, it checked all the PCI instances and connected the drivers to the mass storage device. However, Xen registered its PCI device with a special class id (0xFF80), so ConnectRecursivelyIfPciMassStorage() couldn't recognize it and skipped the driver connecting for Xen PCI devices. In the end, the Xen block device wasn't initialized until EfiBootManagerConnectAll() was called, and it's already too late to load NvVars. This commit connects the Xen drivers in ConnectRecursivelyIfPciMassStorage() so that Xen can use the file-based NvVars. v3: * Introduce XenDetected() to cache the result of Xen detection instead of relying on PcdPciDisableBusEnumeration. v2: * Cosmetic changes Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-05-31OvmfPkg: raise DXEFV size to 10 MBGary Lin3-9/+9
We reached the size limit again. Building OVMF with the following command $ ./OvmfPkg/build.sh -D SECURE_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D HTTP_BOOT_ENABLE and it ended up with GenFds.py... GenFv: ERROR 3000: Invalid : error 7000: Failed to generate FV the required fv image size 0x900450 exceeds the set fv image size 0x900000 Since the new UEFI features, such as HTTPS, are coming, we need a larger DEXFV eventually. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Laszlo Ersek <lersek@redhat.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Gary Lin <glin@suse.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2016-05-27OvmfPkg/PlatformBootManagerLib: keep the logo after connecting devicesLaszlo Ersek1-5/+0
OVMF (unlike ArmVirtPkg) has traditionally cleared the screen after connecting devices. This is not really necessary, and keeping the logo up while the progress bar is advancing at the bottom looks great. So don't clear the screen. Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@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>
2016-05-27OvmfPkg/PlatformBootManagerLib: bring back the progress barLaszlo Ersek1-0/+17
OVMF's Platform BDS used to have a nice progress bar (with IntelFrameworkModulePkg BDS). We can restore it by copying the PlatformBootManagerWaitCallback() function verbatim from Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c It can be tested by passing the following option to QEMU (5 seconds): -boot menu=on,splash-time=5000 Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Ruiyu Ni <ruiyu.ni@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>
generated by cgit v1.1 at 2024-10-10 10:01:05 +0000