summaryrefslogtreecommitdiff
path: root/OvmfPkg
AgeCommit message (Collapse)Author
2014-03-22OvmfPkg: PlatformDxe: connect RouteConfig() to platform dataLaszlo Ersek
Establish the full stack of conversions when modifying the platform configuration: ConfigResp -- form engine / HII communication | [ConfigToBlock] | v MAIN_FORM_STATE -- binary representation of form/widget state | [FormStateToPlatformConfig] | v PLATFORM_CONFIG -- accessible to DXE and UEFI drivers | [PlatformConfigSave] | v UEFI non-volatile variable -- accessible to external utilities Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15375 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-22OvmfPkg: PlatformDxe: connect ExtractConfig() to platform dataLaszlo Ersek
Establish the full stack of conversions in retrieving the platform configuration: MultiConfigAltResp -- form engine / HII communication ^ | [BlockToConfig] | MAIN_FORM_STATE -- binary representation of form/widget state ^ | [PlatformConfigToFormState] | PLATFORM_CONFIG -- accessible to DXE and UEFI drivers ^ | [PlatformConfigLoad] | UEFI non-volatile variable -- accessible to external utilities Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15374 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-22OvmfPkg: PlatformDxe: add save and discard buttons to the formLaszlo Ersek
The RouteConfig() function is also called now as expected. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15373 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-22OvmfPkg: PlatformDxe: get available resolutions from GOPLaszlo Ersek
Generate the options for the drop-down list from the GOP resolutions. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15372 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-22OvmfPkg: QemuVideoDxe: serialize Start() against callbacksLaszlo Ersek
If Start() succeeds, the callback is only executed when the setup is complete (on the stack of RestoreTPL()), rather than on the stack of InstallMultipleProtocolInterfaces(), when the driver setup may yet be theoretically incomplete. If Start() fails, the protocol interface will have been uninstalled (rolled back) by the time the callback runs (again, on the stack of RestoreTPL()). Since protocol notification callbacks begin with locating the protocol interface in question, such attempts to locate will fail immediately and save some work in the callback. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15371 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-22OvmfPkg/PlatformDxe: Silence warning seen with GCC48 IA32Jordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15370 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-22OvmfPkg: PlatformDxe: add form widgets for video modesLaszlo Ersek
In this patch we populate the form with the two widgets related to video resolution: - A read-only string field displaying the preference for the next boot. - A drop-down list offering choices for changing the setting. This list is implemented with dynamically generated IFR opcodes. (In general, the current preference may be missing, or it may be invalid for the available video RAM size. The list of possible new settings is filtered with the video RAM size.) Because the form now becomes able to receive input, we must also implement ExtractConfig(). This function tells the HII engine about the state of the widgets. For now we set up both widgets with static data only: - The current preference always says "Unset". The driver code is still isolated from the backend (the UEFI variable store). - The list of possible resolutions offers 800x600 only. We don't interrogate the GOP yet. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15369 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-22OvmfPkg: PlatformDxe: introduce state for the main formLaszlo Ersek
We'll need a C language (ie. structure) representation for the state of the visual elements on the form. We choose the Buffer Storage kind (see 29.2.5.6 "Storage" in UEFI 2.4A), because it's easy to work with. Note that the structure added in this patch has nothing to do with UEFI non-volatile variables. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15368 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-22OvmfPkg: PlatformDxe: add an empty HII formLaszlo Ersek
... which opens from the Device Manager window. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15367 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-22OvmfPkg: PlatformDxe: set preferred video resolution from platform configLaszlo Ersek
The GraphicsConsoleDxe driver (in MdeModulePkg/Universal/Console) determines the preferred video resolution from the dynamic PCDs - gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution - gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution Setting the graphics resolution during boot is useful when the guest OS (for lack of a dedicated display driver) continues to work with the original GOP resolution and framebuffer. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15366 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-22OvmfPkg: PlatformDxe: utility functions for saving / loading configurationLaszlo Ersek
The two functions introduced here allow the saving and loading of platform configuration to/from the non-volatile variable store. The PLATFORM_CONFIG structure and the two functions that take it / return it are generally meant for any DXE or UEFI driver that needs to access platform configuration. For now we keep this small "library" internal to PlatformDxe. The PLATFORM_CONFIG wire format is intended only to grow over time (as long as the variable GUID remains unchanged). At the introduction of new fields, new feature flags must be added, and recognized in PlatformConfigLoad(). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15365 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-22OvmfPkg: introduce empty PlatformDxeLaszlo Ersek
This DXE driver will load/save persistent values for OVMF's config knobs, plus expose those knobs via HII. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15364 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-22OvmfPkg: introduce gOvmfPlatformConfigGuidLaszlo Ersek
This GUID should become a new "namespace" for UEFI variables that are specific to OVMF configuration (as opposed to standard UEFI global variables). We'll also use it as the GUID of the related HII form-set (ie. the interactive user interface). Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15363 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-22OvmfPkg: non-null PcdLib instance for GraphicsConsoleDxeLaszlo Ersek
GraphicsConsoleDxe (a UEFI_DRIVER under MdeModulePkg/Universal/Console) determines the preferred video resolution from the dynamic PCDs - gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution - gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution In one of the next patches, we'd like to change these PCDs. In order for GraphicsConsoleDxe to retrieve the new values dynamically, - it must be linked with the non-null instance of PcdLib, - OvmfPkg must provide dynamic defaults. We keep MdeModulePkg's 800x600 default resolution. (The UEFI specification requires video drivers to support 800x600.) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15362 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-13OvmfPkg: BDS: QemuBootOrder: don't leak unreferenced boot optionsLaszlo Ersek
The Boot#### variables that have become unreferenced in the new BootOrder variable won't ever be automatically reused for booting. They are "unreachable" resources that take up room in the variable store. Make an effort to remove them. This should plug the leak which, given sufficient reboots, exhausts the variable store with stale Boot#### variables and renders the VM unbootable. Reported-by: Michael Chang <mchang@suse.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> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15327 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-13OvmfPkg: BDS: remove historic (now defunct) boot mode hackLaszlo Ersek
When PI can distinguish the "full config" boot mode from "assume no changes", then the following BDS logic is correct: if BootMode == BOOT_WITH_FULL_CONFIGURATION: // // connect all devices // create & append each default boot option that's missing // BdsLibConnectAll BdsLibEnumerateAllBootOption else if BootMode == BOOT_ASSUMING_NO_CONFIGURATION_CHANGES: // // just stick with current BootOrder and the Boot#### variables // referenced by it // In theory, the first branch is intended to run infrequently, and the "assume no changes" branch should run most of the time. However, some platforms can't tell these two boot modes apart. The following substitute had been introduced: // // Technically, always assume "full config", but the BootMode HOB is // actually meaningless wrt. to "full config" or "assume no changes". // ASSERT (BootMode == BOOT_WITH_FULL_CONFIGURATION); // // Key off the existence of BootOrder. Try to prepare an in-memory list // of boot options, based on BootOrder and the referenced Boot#### // variables. // Status = BdsLibBuildOptionFromVar() // // If that succeeded, we'll treat it as "assume no changes". If it // failed (*only* if it failed), we'll build default boot options, // calling it "full config": // if EFI_ERROR(Status): BdsLibConnectAll() BdsLibEnumerateAllBootOption(BootOptionList) What we have now in OVMF is a mixture of the hack, and the behavior that's theoretically correct for "full config": - We assert "full config" -- this is OK. - We call "connect all" and "enumerate all" deliberately -- this is OK too. It matches "full config" which we assert. - However, we also have the hack in place, which had been meant as an alternative. In order to clean this up, we either need to restore the hack to its original form (ie. comment out the unconditional calls again), or we ought to remove the hack altogether. The unconditional "connect all" + "enumerate all" calls are the correct approach for OVMF, because we want, in fact, to start with "full config". The QEMU boot order specification and the set of emulated devices might change "out of band", which excludes "assume no changes". In other words, removing the hack corresponds to the "real production" case that the comment hints at. Because SetBootOrderFromQemu() may change the BootOrder NvVar, we must preserve the BdsLibBuildOptionFromVar() function call, in order to refresh the in-memory list with the new boot priorities. (The last step of BdsLibEnumerateAllBootOption() is such a call too.) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15326 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-05OvmfPkg: raise DXEFV size to 8 MBLaszlo Ersek
This fixes build errors like: GenFds.py... the required fv image size 0x71b118 exceeds the set fv image size 0x700000 which is reported at least for: (a) -b DEBUG -D SECURE_BOOT_ENABLE -t GCC44, (b) -b DEBUG -D SECURE_BOOT_ENABLE -t GCC48 -D CSM_ENABLE Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15309 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg: Add DebugAgentLib for Library class mapping for DXE_DRIVERJordan Justen
This is needed for BootScriptExecutorDxe. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15308 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg: S3 Resume: pull in BootScriptExecutorDxeLaszlo Ersek
This driver (from "MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/BootScriptExecutorDxe.inf") is first loaded normally during DXE. When the EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed by any DXE driver (purely as a form of notification), the driver reloads itself to reserved memory. During S3 Resume / PEI, the driver image is executed from there. In order to access the boot script saved during S3 Suspend, LockBox access is needed. The boot script is transferred internal to PiDxeS3BootScriptLib: Both S3SaveStateDxe and BootScriptExecutorDxe are statically linked against PiDxeS3BootScriptLib. Whichever is loaded first (during normal boot, in the DXE phase), allocates the root storage for the script. The address is then passed between the PiDxeS3BootScriptLib instances living in the two separate drivers thru the dynamic PcdS3BootScriptTablePrivateDataPtr PCD. Dependencies: BootScriptExecutorDxe gEfiLockBoxProtocolGuid [OvmfPkg/AcpiS3SaveDxe] S3BootScriptLib [PiDxeS3BootScriptLib] SmbusLib [BaseSmbusLibNull] LockBoxLib [OvmfPkg/Library/LockBoxLib] LockBoxLib [OvmfPkg/Library/LockBoxLib] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15307 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg: S3 Resume: fake LockBox protocol for BootScriptExecutorDxeLaszlo Ersek
BootScriptExecutorDxe, to be pulled in in the next patch, was written with the SMM implementation of LockBox in mind. That implementation is split in the following three parts: - client side (DXE/PEI) library, - SMM driver producing gEfiLockBoxProtocolGuid, - driver side (SMM) library. BootScriptExecutorDxe includes the client side LockBoxLib. So that the library can communicate with the SMM LockBox driver, BootScriptExecutorDxe has a Depex on gEfiLockBoxProtocolGuid, normally installed by the SMM LockBox driver. This is actually not a hard dependency, it just ensures correct load order between BootScriptExecutorDxe and MdeModulePkg/Universal/LockBox/SmmLockBox. The (client side) LockBox library instance in OVMF doesn't depend on a separate driver that produces gEfiLockBoxProtocolGuid. Nothing produces that GUID right now in OVMF. This prevents BootScriptExecutorDxe from loading. Install gEfiLockBoxProtocolGuid in our only S3-specific, custom DXE driver, in order to enable loading of BootScriptExecutorDxe. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15306 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg: S3 Suspend: save boot script after ACPI contextLaszlo Ersek
The trigger to actually save the boot script is the installation of EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL, to be performed by any DXE driver. Installation of the protocol also locks down SMM (as its name indicates) and (in theory) prevents further LockBox access. We cannot install this protocol before BdsLibBootViaBootOption() is called (eg. in OVMF's PlatformBdsPolicyBehavior()), because BdsLibBootViaBootOption() calls EFI_ACPI_S3_SAVE_PROTOCOL.S3Save(), which needs LockBox access. We also can't install the protocol after BdsLibBootViaBootOption() returns, simply because control is never returned to us. Therefore modify our EFI_ACPI_S3_SAVE_PROTOCOL implementation so that the boot script is prepared and installed internally to S3Save(). (The boot script must contain at least one opcode, otherwise S3BootScriptLib runs into an assertion failure. We add a harmless (no-op) "information" opcode.) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15305 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg: S3 Suspend: enable creation/saving of an S3 Boot ScriptLaszlo Ersek
"MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveStateDxe.inf" produces the EFI_S3_SAVE_STATE_PROTOCOL which allows creation and saving of an S3 Boot Script, to be replayed in PEI during S3 Resume. The script contains opcodes and opcode arguments to configure CPU, PCI and IO resources. S3SaveStateDxe relies on the S3BootScriptLib library. The Null implementation is not useful for actually saving the boot script, we need the PiDxeS3BootScriptLib instance. The PiDxeS3BootScriptLib library instance depends on LockBoxLib, implemented for OVMF in one of the previous patches. PiDxeS3BootScriptLib also depends on SmbusLib. For now we opt for the Null instance of the latter. It means that SMBus commands in the boot script will have no effect when interpreted during S3 Resume. This should be fine for OvmfPkg and QEMU. EFI_S3_SAVE_STATE_PROTOCOL [S3SaveStateDxe] S3BootScriptLib [PiDxeS3BootScriptLib] SmbusLib [BaseSmbusLibNull] LockBoxLib [OvmfPkg/Library/LockBoxLib] When the EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL is installed by any DXE driver (purely as a form of notification), the S3SaveStateDxe driver saves the boot script to EfiACPIMemoryNVS, and links it into the LockBox. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15304 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg: S3 Suspend: save ACPI contextLaszlo Ersek
"OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf" (originally: "IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe/AcpiS3SaveDxe.inf") produces the EFI_ACPI_S3_SAVE_PROTOCOL. When found, this protocol is automatically invoked by BdsLibBootViaBootOption(), in file "IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c", right before booting a boot option, to save ACPI S3 context. At that point during BDS, our AcpiPlatformDxe driver will have installed the FACS table (which AcpiS3SaveDxe has a use-time dependency upon). With regard to dependencies: AcpiS3SaveDxe implements EFI_ACPI_S3_SAVE_PROTOCOL by relying on LockBoxLib. BdsLibBootViaBootOption() EFI_ACPI_S3_SAVE_PROTOCOL [AcpiS3SaveDxe] LockBoxLib [OvmfPkg/Library/LockBoxLib] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [jordan.l.justen@intel.com: Remove EmuNvramLib] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15303 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg: S3 Suspend: import specialized copy of AcpiS3SaveDxeLaszlo Ersek
"IntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe/AcpiS3SaveDxe.inf" currently specifies a DepEx on gEfiMpServiceProtocolGuid (MP Services). The justification is the following code sequence: InstallAcpiS3Save() if PcdFrameworkCompatibilitySupport is set: InstallAcpiS3SaveThunk() if EFI_MP_SERVICES_PROTOCOL is available: GetVariable(ACPI_GLOBAL_VARIABLE) In English, the AcpiS3SaveDxe driver insists on the presence of MP Services *unconditionally* because, - if PcdFrameworkCompatibilitySupport is set (the default is false), - and MP Services are available (which is constant true under the above condition), then the AcpiS3SaveDxe driver would like to get the ACPI_GLOBAL_VARIABLE variable from the MP Services driver, rather than setting it itself. The DepEx prevents AcpiS3SaveDxe from loading under OvmfPkg, since we provide no MP Services implementation. This is particularly broken since the default PcdFrameworkCompatibilitySupport value is FALSE, making the entire code that would look at EFI_MP_SERVICES_PROTOCOL dead. Copy AcpiS3SaveDxe to OvmfPkg, substitute PcdFrameworkCompatibilitySupport with constant FALSE, and remove all code that becomes dead, including the DepEx. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15302 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg: implement LockBoxLibLaszlo Ersek
The S3 suspend/resume infrastructure depends on the LockBox library class. The edk2 tree currently contains Null and SMM instances. The Null instance is useless, and the SMM instance would require SMM emulation by including the SMM core and adding several new drivers, which is deemed too complex. Hence add a simple LockBoxLib instance for OVMF. jordan.l.justen@intel.com: * use PCDs instead of EmuNvramLib - clear memory in PlatformPei on non S3 boots * allocate NVS memory and store a pointer to that memory - reduces memory use at fixed locations Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15301 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg: S3 Resume: pull in PEIM orchestrating S3 ResumeLaszlo Ersek
"UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf" produces the EFI_PEI_S3_RESUME2 PEIM-to-PEIM Interface. When the platform-specific initialization code (in PEI) sets the Boot Mode to BOOT_ON_S3_RESUME, the DXE IPL (which is the last step in PEI) skips the DXE phase entirely, and executes the S3 Resume PEIM through the EFI_PEI_S3_RESUME2 interface instead. (See DxeLoadCore() in "MdeModulePkg/Core/DxeIplPeim/DxeLoad.c".) S3Resume2Pei depends on LockBoxLib. EFI_PEI_S3_RESUME2 [S3Resume2Pei] LockBoxLib [OvmfPkg/Library/LockBoxLib] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15300 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg/PlatformPei: Allocate PEI FV as ACPI NVS if S3 is supportedJordan Justen
On S3 resume, we skip decompression of the PEI FV, and expect to jump directly into it. For this to work, we need the OS to leave the memory range untouched. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15299 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg: PlatformPei: reserve early page tables on X64Laszlo Ersek
On X64, the reset vector code in "OvmfPkg/ResetVector/Ia32/PageTables64.asm" identity maps the first 4GB of RAM for PEI, consuming six frames starting at 8MB. This range is declared by the PcdOvmfSecPageTablesBase/Size PCDs. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> [jordan.l.justen@intel.com: Move to MemDetect.c; use PCDs] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15298 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg: PlatformPei: reserve SEC/PEI temp RAM for S3 resumeLaszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> [jordan.l.justen@intel.com: move to MemDetect.c; use PCDs] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15297 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg/Sec: Don't decompress the FV on S3 resumeJordan Justen
Since we marked the FV at PcdOvmfPeiMemFvBase as ACPI NVS memory, we can use it on S3 resume. The FV at PcdOvmfDxeMemFvBase may have been overwritten by the OS, but we do not use it's contents on S3 resume. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15296 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg/PlatformPei: Skip various items for S3 resumeJordan Justen
We will not be running DXE on S3 resume, so we don't need to do these initialization items: * Reserve EMU Variable memory range * Declare Firmware volumes * Add memory HOBs v5: * Move MiscInitialization back to running on S3 resume Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15295 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg: Add section of memory to use for PEI on S3 resumeJordan Justen
This 32k section of RAM will be declared to the PEI Core on S3 resume to allow memory allocations during S3 resume PEI. If the boot mode is BOOT_ON_S3_RESUME, then we publish the pre-reserved PcdS3AcpiReservedMemory range to PEI. If the boot mode is not BOOT_ON_S3_RESUME, then we reserve this range as ACPI NVS so the OS will not use it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15294 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg/PlatformPei: Detect S3 support for QEMU / KVMJordan Justen
QEMU indicates whether S3 is supported or not in the fw-cfg interface. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15293 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg QemuFwCfgLib: determine if S3 support is explicitly enabledLaszlo Ersek
Such a packaged query function will come in handy in the following patches. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [jordan.l.justen@intel.com: check for enabled rather than disabled] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15292 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg/PlatformPei: Add mBootMode driver variableJordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15291 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-04OvmfPkg: PlatformPei: detect S3 Resume in CMOS and set boot mode accordinglyLaszlo Ersek
Data is transferred between S3 Suspend and S3 Resume as follows: S3 Suspend (DXE): (1) BdsLibBootViaBootOption() EFI_ACPI_S3_SAVE_PROTOCOL [AcpiS3SaveDxe] - saves ACPI S3 Context to LockBox ---------------------+ (including FACS address -- FACS ACPI table | contains OS waking vector) | | - prepares boot script: | EFI_S3_SAVE_STATE_PROTOCOL.Write() [S3SaveStateDxe] | S3BootScriptLib [PiDxeS3BootScriptLib] | - opcodes & arguments are saved in NVS. --+ | | | - issues a notification by installing | | EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL | | | | (2) EFI_S3_SAVE_STATE_PROTOCOL [S3SaveStateDxe] | | S3BootScriptLib [PiDxeS3BootScriptLib] | | - closes script with special opcode <---------+ | - script is available in non-volatile memory | via PcdS3BootScriptTablePrivateDataPtr --+ | | | BootScriptExecutorDxe | | S3BootScriptLib [PiDxeS3BootScriptLib] | | - Knows about boot script location by <----+ | synchronizing with the other library | instance via | PcdS3BootScriptTablePrivateDataPtr. | - Copies relocated image of itself to | reserved memory. --------------------------------+ | - Saved image contains pointer to boot script. ---|--+ | | | | Runtime: | | | | | | (3) OS is booted, writes OS waking vector to FACS, | | | suspends machine | | | | | | S3 Resume (PEI): | | | | | | (4) PlatformPei sets S3 Boot Mode based on CMOS | | | | | | (5) DXE core is skipped and EFI_PEI_S3_RESUME2 is | | | called as last step of PEI | | | | | | (6) S3Resume2Pei retrieves from LockBox: | | | - ACPI S3 Context (path to FACS) <------------------|--|--+ | | | +------------------|--|--+ - Boot Script Executor Image <----------------------+ | | | | (7) BootScriptExecutorDxe | | S3BootScriptLib [PiDxeS3BootScriptLib] | | - executes boot script <-----------------------------+ | | (8) OS waking vector available from ACPI S3 Context / FACS <--+ is called Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> [jordan.l.justen@intel.com: move code into BootModeInitialization] Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15290 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-03OvmfPkg: QemuVideoDxe: add further BOCHS modesLaszlo Ersek
This brings the list of BOCHS video modes to par with the QEMU QXL implementation. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15289 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-03OvmfPkg: QemuVideoDxe: filter BOCHS modes vs. available frame buffer sizeLaszlo Ersek
In the next patch we'll add many new BOCHS modes, some of which require large frame buffers. The size of the QXL VGA compatibility framebuffer can be changed with the -global qxl-vga.vgamem_mb=$NUM_MB QEMU option. If $NUM_MB would exceed 32, then the following two QEMU options are necessary instead: -global qxl-vga.vgamem_mb=$NUM_MB \ -global qxl-vga.ram_size_mb=$((NUM_MB*2)) because the compatibility framebuffer can't cover more than half of PCI BAR #0. The latter defaults to 64MB in size, and is controlled by "ram_size_mb". Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15288 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-03OvmfPkg: QemuVideoDxe: clarify QEMU_VIDEO_MODE_DATA.ModeNumberLaszlo Ersek
The field name "ModeNumber" in QEMU_VIDEO_MODE_DATA is misleading -- it is not immediately obvious whether this field carries a client-visible mode number, in the GOP sense, or an internal, card type specific mode index. After checking all references, rename the field to "InternalModeIndex". Also, when filling in the card type independent QEMU_VIDEO_MODE_DATA array from the card type specific mode array, distinguish the GOP mode number from the internal mode index in the debug message. This patch effects no functional changes. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15287 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-03OvmfPkg: QemuVideoDxe: eliminate useless Private->HardwareNeedsStartingLaszlo Ersek
Currently, QemuVideoGraphicsOutputQueryMode() reports EFI_NOT_STARTED when this boolean field is set. However, QemuVideoGraphicsOutputQueryMode() is only available to callers after the GOP interface has been installed. That in turn implies that the following partial call tree has succeeded without errors: QemuVideoControllerDriverStart() QemuVideoGraphicsOutputConstructor() QemuVideoGraphicsOutputSetMode(... 0 ...) HardwareNeedsStarting = FALSE InstallMultipleProtocolInterfaces(... GOP ...) That is, when QemuVideoGraphicsOutputQueryMode() is reached, HardwareNeedsStarting is always FALSE. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15286 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-03OvmfPkg: QemuVideoDxe: plug remaining leaks in Stop()Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15285 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-03OvmfPkg: QemuVideoDxe: disentangle UEFI driver model use in Stop()Laszlo Ersek
A bus driver needs to pay attention whether its Stop() function is being called on the "main" controller handle (NumberOfChildren == 0) or on the child handles (NumberOfChildren > 0). In QemuVideoDxe, all our resources are associated with the one child handle (and the Private data structure) *except* the top-level PciIo protocol reference. Be conscious of which mode Stop() is being called for. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15284 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-03OvmfPkg: QemuVideoDxe: simplify UEFI driver model use in Supported() / Start()Laszlo Ersek
A bus driver is allowed to ignore the actual value of RemainingDevicePath in Supported() and Start(), and to produce all child handles at once. This in effect means the following invariants for QemuVideoDxe: - (RemainingDevicePath == NULL), and - (Private->GopDevicePath != NULL) Simplify Supported() and Start() by substituting constant TRUE and FALSE (as appropriate) in expressions that check RemainingDevicePath and/or Private->GopDevicePath. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15283 6f19259b-4bc3-4df7-8a09-765794883524
2014-03-03OvmfPkg: QemuVideoDxe: tidy up error checking/handling in & under Start()Laszlo Ersek
In QemuVideoControllerDriverStart(): - remove redundant zero-initialization of: - Private->Handle (2 locations) - Private->GopDevicePath (when at devpath end) - remove fields used for error handling only: - PciAttributesSaved - tigthen scope of temporaries: - MmioDesc - AcpiDeviceNode - supplement missing error checks: - AppendDevicePathNode() can fail with out-of-memory (2 locations) - when installing GopDevicePath - retval of QemuVideoGraphicsOutputConstructor() (can justifiedly fail with out-of-resources) - plug leaks on error: - free GopDevicePath (AppendDevicePathNode() allocates dynamically) - uninstall GopDevicePath - free Private->ModeData - call QemuVideoGraphicsOutputDestructor() - uninstall GOP In QemuVideoGraphicsOutputConstructor(), called by Start(): - supplement missing error checks: - QemuVideoGraphicsOutputSetMode() retval (it can fail with out-of-resources) - plug leaks on error: - free Mode->Info - free Mode In QemuVideoCirrusModeSetup() and QemuVideoBochsModeSetup(), both called by Start(): - supplement missing error checks: - AllocatePool() can fail in both In QemuVideoGraphicsOutputDestructor(), called by Start() on the error path: - plug leaks: - free Private->LineBuffer, which is allocated in Start() -> Constructor() -> SetMode() In QemuVideoGraphicsOutputSetMode(), called by Start() indirectly: - remove redundant zero-assignment to: - Private->LineBuffer Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-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@15282 6f19259b-4bc3-4df7-8a09-765794883524
2014-02-09OvmfPkg: QemuBootOrder: initialize IsFinal variable to make MSVC happyMauro Faccenda
The BOOLEAN IsFinal variable initialization isn't properly seen by MSVC. To make it compile OVMF the variable needs to be initialized. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Mauro Faccenda <faccenda@gmail.com> 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@15214 6f19259b-4bc3-4df7-8a09-765794883524
2014-02-09OvmfPkg/PlatformPei: Remove duplicate Xen memory map debug messageJordan Justen
This duplicate message was intended to be removed from r15207 before it was committed. (It was pointed out by Wei Liu.) Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15213 6f19259b-4bc3-4df7-8a09-765794883524
2014-02-01OvmfPkg/PlatformPei: Add RAM for Xen in InitializeRamRegionsJordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15207 6f19259b-4bc3-4df7-8a09-765794883524
2014-02-01OvmfPkg/PlatformPei: Add InitializeRamRegions functionJordan Justen
In the next commit we will update the Xen boot path to also use this function. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15206 6f19259b-4bc3-4df7-8a09-765794883524
2014-02-01OvmfPkg/PlatformPei: Merge Xen support into MemMapInitializationJordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15205 6f19259b-4bc3-4df7-8a09-765794883524
2014-02-01OvmfPkg/PlatformPei: Set PcdPciDisableBusEnumeration in InitializeXenJordan Justen
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15204 6f19259b-4bc3-4df7-8a09-765794883524
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-19 06:20:28 +0000