Olivier Martin [Fri, 11 Apr 2014 11:02:59 +0000 (11:02 +0000)]
ArmPlatformPkg/Bds: Do not start all devices when starting an OS loader
EFI OS Loader application will be responsible to start their needed drivers.
While other EFI applications (eg: EFI Shell) expect to have all their drivers
started when they run.
Olivier Martin [Fri, 11 Apr 2014 10:59:48 +0000 (10:59 +0000)]
ArmPlatformPkg/Bds: Introduced helper function to detect if an Ascii/Unicode string is printable
Some limitations:
- it only supports unicode string that use ASCII character (< 0x100)
- single character ASCII strings are interpreted as Unicode string
- string cannot be longer than 2 x BOOT_DEVICE_OPTION_MAX (600 bytes)
Olivier Martin [Fri, 11 Apr 2014 10:56:02 +0000 (10:56 +0000)]
ArmPlatformPkg/Bds: Decoupled OptionalData for the EFI application boot entry from the Linux loader
OptionalData for EFI Application does not contain any more specific information about the ArmPlatformPkg/Bds.
OptionalData now only contains the data pass to the EFI application.
Fu Siyuan [Thu, 10 Apr 2014 02:25:49 +0000 (02:25 +0000)]
Fix a bug in IP driver that the fragment overlap check may be skipped incorrectly. Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye, Ting <ting.ye@intel.com> Reviewed-by: Jin, Eric <eric.jin@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Olivier Martin [Tue, 8 Apr 2014 18:02:32 +0000 (18:02 +0000)]
ArmPlatformPkg/NorFlashDxe: Fix coding mistakes that would prevent Runtime mode
- No allocation during Runtime mode (post ExitBootServices())
- Allocate all the persistent data into runtime space
- Do not access BootServices API during Runtime mode
Olivier Martin [Tue, 8 Apr 2014 17:59:00 +0000 (17:59 +0000)]
ArmPlatformPkg/PL031RealTimeClock: Fixed driver to support UEFI Runtime Services
- Removed PCD base address from the macro definition. The base address needs to be fixup when the driver runs in UEFI Runtime mode
- Added the PL031 controller memory region to the Runtime UEFI Memory Mapped IO
- Caught the gEfiEventVirtualAddressChangeGuid event to fixup the PL031 Base address
The ExtractGuidedSectionLib library class allows decompressor modules to
register themselves (keyed by GUID) with it, and it allows clients to
decompress file sections with a registered decompressor module that
matches the section's GUID.
BaseExtractGuidedSectionLib is a library instance (of type BASE) for this
library class. It has no constructor function.
LzmaCustomDecompressLib is a compatible decompressor module (of type
BASE). Its section type GUID is
When OVMF's SecMain module starts, the LzmaCustomDecompressLib constructor
function is executed, which registers its LZMA decompressor with the above
GUID, by calling into BaseExtractGuidedSectionLib:
LzmaDecompressLibConstructor() [GuidedSectionExtraction.c]
ExtractGuidedSectionRegisterHandlers() [BaseExtractGuidedSectionLib.c]
GetExtractGuidedSectionHandlerInfo()
PcdGet64 (PcdGuidedExtractHandlerTableAddress) -- NOTE THIS
Later, during a normal (non-S3) boot, SecMain utilizes this decompressor
to get information about, and to decompress, sections of the OVMF firmware
image:
Notably, only the extraction depends on full-config-boot; the registration
of LzmaCustomDecompressLib occurs unconditionally in the SecMain EFI
binary, triggered by the library constructor function.
This is where the bug happens. BaseExtractGuidedSectionLib maintains the
table of GUIDed decompressors (section handlers) at a fixed memory
location; selected by PcdGuidedExtractHandlerTableAddress (declared in
MdePkg.dec). The default value of this PCD is 0x1000000 (16 MB).
This causes SecMain to corrupt guest OS memory during S3, leading to
random crashes. Compare the following two memory dumps, the first taken
right before suspending, the second taken right after resuming a RHEL-7
guest:
The "EGSI" signature corresponds to EXTRACT_HANDLER_INFO_SIGNATURE
declared in
MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.c.
Additionally, the gLzmaCustomDecompressGuid (quoted above) is visible at
guest-phys offset 0x1000020.
Fix the problem as follows:
- Carve out 4KB from the 36KB gap that we currently have between
PcdOvmfLockBoxStorageBase + PcdOvmfLockBoxStorageSize == 8220 KB
and
PcdOvmfSecPeiTempRamBase == 8256 KB.
- Point PcdGuidedExtractHandlerTableAddress to 8220 KB (0x00807000).
- Cover the area with an EfiACPIMemoryNVS type memalloc HOB, if S3 is
supported and we're not currently resuming.
The 4KB size that we pick is an upper estimate for
BaseExtractGuidedSectionLib's internal storage size. The latter is
calculated as follows (see GetExtractGuidedSectionHandlerInfo()):
OVMF sets PcdMaximumGuidedExtractHandler to 16 decimal (which is the
MdePkg default too), yielding 32 + 16 * (16 + 8 + 8) == 544 bytes.
Regarding the lifecycle of the new area:
(a) when and how it is initialized after first boot of the VM
The library linked into SecMain finds that the area lacks the signature.
It initializes the signature, plus the rest of the structure. This is
independent of S3 support.
Consumption of the area is also limited to SEC (but consumption does
depend on full-config-boot).
(b) how it is protected from memory allocations during DXE
It is not, in the general case; and we don't need to. Nothing else links
against BaseExtractGuidedSectionLib; it's OK if DXE overwrites the area.
(c) how it is protected from the OS
When S3 is enabled, we cover it with AcpiNVS in InitializeRamRegions().
When S3 is not supported, the range is not protected.
(d) how it is accessed on the S3 resume path
Examined by the library linked into SecMain. Registrations update the
table in-place (based on GUID matches).
(e) how it is accessed on the warm reset path
If S3 is enabled, then the OS won't damage the table (due to (c)), hence
see (d).
If S3 is unsupported, then the OS may or may not overwrite the
signature. (It likely will.) This is identical to the pre-patch status.
Olivier Martin [Thu, 3 Apr 2014 20:05:30 +0000 (20:05 +0000)]
ArmPlatformPkg/PrePi: Use the same calculation to declare the stack size as in the entrypoint
The stack size in the entrypoint (ie: $ARCH/ModuleEntryPoint.S) is calculated such as
StackSize = PrimaryCoreStack + (core_count - 1) * SecondaryCoreStack
While we were declaring the stacksize into the stack hob as:
StackSize = PrimaryCoreStack + (cluster * 8) * SecondaryCoreStack
If the number of cluster (ie: PcdClusterCount) were not defined correctly then
the stack size declaration were not correct.
It could cause stack corruption if the allocator allocates memory in this range.
Olivier Martin [Wed, 2 Apr 2014 17:32:29 +0000 (17:32 +0000)]
ArmPkg: Fixed GetEnvironmentVariable() when the UEFI Variable did not exist
The function was allocating a buffer for the read value from the UEFI Variable.
But it was returning the pointer of the default value when the variable was
not present.
It could cause error when the default value and the returned value were free
when these addresses were the same (double FreePool on the same address).
Paolo Bonzini [Mon, 31 Mar 2014 20:36:23 +0000 (20:36 +0000)]
OvmfPkg: add a catch-all match for PCI devices in the OpenFirmware path
In many cases, the second node in /pci@i0cf8/XYZ@DD,FF node is enough
to match a UEFI device path; a typical cases is a NIC that is assigned
from the host to the guest. Add a catch-all case for PCI devices, and
reuse it for NICs since it works well for those too.
Paolo Bonzini [Mon, 31 Mar 2014 20:36:15 +0000 (20:36 +0000)]
OvmfPkg: non-null PcdLib instance for the CSM VideoDxe
VideoDxe is a UEFI_DRIVER, so it has by default a null instance
of PcdLib. It accesses two PCDs that are now dynamic
(gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution
and gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution).
Similar to r15362 (OvmfPkg: non-null PcdLib instance for
GraphicsConsoleDxe, 2014-03-22), we need to specify a non-null
instance of PcdLib.
This patch unbreaks the CSM VideoDxe module for OvmfPkg.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paolo Bonzini <pbonzini@redhat.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@15421 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek [Mon, 31 Mar 2014 20:36:06 +0000 (20:36 +0000)]
OvmfPkg: AcpiPlatformDxe: download ACPI tables from QEMU
Recent qemu versions compose all ACPI tables on the host side, according
to the target hardware configuration, and make the tables available to any
guest firmware over fw_cfg.
See version compatibility information below.
The feature moves the burden of keeping ACPI tables up-to-date from boot
firmware to qemu (which is the source of hardware configuration anyway).
This patch adds client code for this feature. Benefits of the
qemu-provided ACPI tables include PCI hotplug for example.
Qemu provides the following three fw_cfg files:
- etc/acpi/rsdp
- etc/acpi/tables
- etc/table-loader
"etc/acpi/rsdp" and "etc/acpi/tables" are similar, they are only kept
separate because they have different allocation requirements in SeaBIOS.
Both of these fw_cfg files contain preformatted ACPI payload.
"etc/acpi/rsdp" contains only the RSDP table, while "etc/acpi/tables"
contains all other tables, concatenated.
The tables in these two fw_cfg files are filled in by qemu, but two kinds
of fields are left incomplete in each table: pointers to other tables, and
checksums (which depend on the pointers).
Qemu initializes each pointer with a relative offset into the fw_cfg file
that contains the pointed-to ACPI table. The final pointer values depend
on where the fw_cfg files, holding the pointed-to ACPI tables, will be
placed in memory by the guest. That is, the pointer fields need to be
"relocated" (incremented) by the base addresses of where "/etc/acpi/rsdp"
and "/etc/acpi/tables" will be placed in guest memory.
This is where the third file, "/etc/table-loader" comes in the picture. It
is a linker/loader script that has several command types:
One command type instructs the guest to download the other two files.
Another command type instructs the guest to increment ("absolutize") a
pointer field (having a relative initial value) in the pointing ACPI
table, present in some fw_cfg file, with the dynamic base address of the
same (or another) fw_cfg file, holding the pointed-to ACPI table.
The third command type instructs the guest to compute checksums over
ranges and to store them.
In edk2, EFI_ACPI_TABLE_PROTOCOL knows about table relationships -- it
handles linkage automatically when a table is installed. The protocol
takes care of checksumming too. RSDP is installed automatically. Hence we
only need to care about the "etc/acpi/tables" fw_cfg file, determining the
boundaries of each ACPI table inside it, and installing those tables.
Qemu compatibility information:
--------------+---------------------+-------------------------------------
qemu version | qemu machine type | effects of the patch
--------------+---------------------+-------------------------------------
up to 1.6.x | any pc-i440fx | None. OVMF's built-in ACPI tables
| | are used.
--------------+---------------------+-------------------------------------
any | up to pc-i440fx-1.6 | None. OVMF's built-in ACPI tables
| | are used.
--------------+---------------------+-------------------------------------
1.7.0 | pc-i440fx-1.7 | Potential guest OS crash, dependent
| (default for 1.7.0) | on guest RAM size.
| |
| | DO NOT RUN OVMF on the (1.7.0,
| | pc-i440fx-1.7) qemu / machine type
| | combination.
--------------+---------------------+-------------------------------------
1.7.1 | pc-i440fx-1.7 | OVMF downloads valid ACPI tables
| (default for 1.7.1) | from qemu and passes them to the
| | guest OS.
--------------+---------------------+-------------------------------------
2.0.0-rc0 | pc-i440fx-1.7 or | OVMF downloads valid ACPI tables
| later | from qemu and passes them to the
| | guest OS.
-------------+---------------------+-------------------------------------
Laszlo Ersek [Mon, 31 Mar 2014 20:35:58 +0000 (20:35 +0000)]
OvmfPkg: AcpiS3SaveDxe: do not load if S3 is unsupported/disabled in qemu
The previous patch ensures that the LockBox is protected during DXE (but
the OS can still drop it) if S3 is unsupported or disabled. However, S3
related drivers not only save data in the lockbox, they allocate objects
with Reserved and AcpiNVS memory types too, which the OS can't (must not)
release. This is a waste when S3 is unsupported or disabled.
In OVMF a good "choke point" for these drivers is the entry point of
AcpiS3SaveDxe. The messages of the following commits are relevant to the
data and control flow:
Laszlo Ersek [Mon, 31 Mar 2014 20:35:50 +0000 (20:35 +0000)]
OvmfPkg: PlatformPei: lifecycle fixes for the LockBox area
If (mBootMode == BOOT_ON_S3_RESUME) -- that is, we are resuming --, then
the patch has no observable effect.
If (mBootMode != BOOT_ON_S3_RESUME && mS3Supported) -- that is, we are
booting or rebooting, and S3 is supported), then the patch has no
observable effect either.
If (mBootMode != BOOT_ON_S3_RESUME && !mS3Supported) -- that is, we are
booting or rebooting, and S3 is unsupported), then the patch effects the
following two fixes:
- The LockBox storage is reserved from DXE (but not the OS). Drivers in
DXE may save data in the LockBox regardless of S3 support, potentially
corrupting any overlapping allocations. Make sure there's no overlap.
- The LockBox storage is cleared. A LockBox inherited across a non-resume
reboot, populated with well-known GUIDs, breaks drivers that want to
save entries with those GUIDs.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Tested-by: Matt Fleming <matt.fleming@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15418 6f19259b-4bc3-4df7-8a09-765794883524
Olivier Martin [Wed, 26 Mar 2014 19:34:32 +0000 (19:34 +0000)]
ArmPkg/ArmLib: Correct Error Handling in AArch64
There are several instances of asserts which do not also handle
the error condition in Release builds.
Because these functions are called in different location of the
code and their parameters might change during the execution, it
is safer to handle the error.
Star Zeng [Tue, 25 Mar 2014 06:56:55 +0000 (06:56 +0000)]
MdeModulePkg/SecurityPkg Variable: Calculate enough space for PlatformLang and Lang variables and use PcdUefiVariableDefaultLangDeprecate to turn off auto update between PlatformLang and Lang variables.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Guo Dong <guo.dong@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15388 6f19259b-4bc3-4df7-8a09-765794883524
Olivier Martin [Mon, 24 Mar 2014 15:26:22 +0000 (15:26 +0000)]
ArmPkg/ArmLib: Renamed Cp15CacheInfo into ArmCacheInfo
CTR (Cache Type Register) has the same format on ARMv7 and AArch64.
Renaming Cp15CacheInfo() into ArmCacheInfo() makes this function
architecture independent.
Laszlo Ersek [Sat, 22 Mar 2014 07:14:09 +0000 (07:14 +0000)]
OvmfPkg: PlatformDxe: connect RouteConfig() to platform data
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
Laszlo Ersek [Sat, 22 Mar 2014 07:13:44 +0000 (07:13 +0000)]
OvmfPkg: QemuVideoDxe: serialize Start() against callbacks
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.
Laszlo Ersek [Sat, 22 Mar 2014 07:13:31 +0000 (07:13 +0000)]
OvmfPkg: PlatformDxe: add form widgets for video modes
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.
Laszlo Ersek [Sat, 22 Mar 2014 07:13:24 +0000 (07:13 +0000)]
OvmfPkg: PlatformDxe: introduce state for the main form
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.
Laszlo Ersek [Sat, 22 Mar 2014 07:13:09 +0000 (07:13 +0000)]
OvmfPkg: PlatformDxe: set preferred video resolution from platform config
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.
Laszlo Ersek [Sat, 22 Mar 2014 07:13:02 +0000 (07:13 +0000)]
OvmfPkg: PlatformDxe: utility functions for saving / loading configuration
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().
Laszlo Ersek [Sat, 22 Mar 2014 07:12:46 +0000 (07:12 +0000)]
OvmfPkg: introduce gOvmfPlatformConfigGuid
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).
Laszlo Ersek [Sat, 22 Mar 2014 07:12:36 +0000 (07:12 +0000)]
OvmfPkg: non-null PcdLib instance for GraphicsConsoleDxe
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.)
leroy.p.leahy [Thu, 20 Mar 2014 22:05:51 +0000 (22:05 +0000)]
Fix TCP4/TCP6 connections. Connections were transitioning into the connected state and the polling was returning an error. Fix the polling routine to return success in this case.
projects / mirror_edk2.git / log