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.
Fu Siyuan [Thu, 20 Mar 2014 06:04:50 +0000 (06:04 +0000)]
Use PXE_OPFLAGS_STATION_ADDRESS_WRITE when setting new MAC address for the NIC in SNP driver. Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Dong, Guo <guo.dong@intel.com> Reviewed-by: Jin, Eric <eric.jin@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Elvin Li [Wed, 19 Mar 2014 02:42:36 +0000 (02:42 +0000)]
Did proper error handling when SetVariable failed, and put RTC write operation at the behind of SetVariable, if SetVariable failed, RTC content could not be changed.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Elvin Li <elvin.li@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15338 6f19259b-4bc3-4df7-8a09-765794883524
Ruiyu Ni [Mon, 17 Mar 2014 08:24:07 +0000 (08:24 +0000)]
Do not reset system when the MemoryTypeInformation variable cannot be written.
Remove the RT attribute for the MemoryTypeInformation variable because it’s not necessary.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15333 6f19259b-4bc3-4df7-8a09-765794883524
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
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.)
Ryan Harkin [Wed, 12 Mar 2014 17:24:48 +0000 (17:24 +0000)]
ArmPlatformPkg/Bds: stop inputting more characters when string is full
If EditHIInputStr() is called, say with a MaxCmdLine of 2, the user is
currently allowed to enter 2 characters.
If the second character is a carriage return/line feed, this is
substituted with a NULL and the function returns.
If the second character is a regular character, the loop terminated and
the function returns. However, the buffer has not been NULL terminated.
This patch prevents the user from entering a regular character as the
final character and ensures that the only way out of the input is by
pressing ESC or ENTER (or equivalent).
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org> Reviewed-by: Olivier Martin <olivier.martin@arm.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15325 6f19259b-4bc3-4df7-8a09-765794883524
Brendan Jackman [Mon, 10 Mar 2014 18:13:13 +0000 (18:13 +0000)]
ShellPkg: ShellCommands/SetVar: Make '-rt' imply '-bs'
It's invalid to set a variable that's available from runtime services but not
from boot services.
Currently if you pass '-rt' without '-bs' you get a generic
'Invalid Parameter' message. We should either print a more useful message in
this case, or make '-rt' imply '-bs' (as this patch does). The Shell Spec is
ambiguous on the matter.
jyao1 [Fri, 7 Mar 2014 03:07:09 +0000 (03:07 +0000)]
Remove unused variable attribute flag.
Signed off by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed by: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Contributed-under: TianoCore Contribution Agreement 1.0
Shumin Qiu [Fri, 7 Mar 2014 01:06:37 +0000 (01:06 +0000)]
1.Add code to check the pointer 'CorrectedPath' in Ls.c line 460 before referenced. 2.Not use explicit comparisons to TRUE or FALSE for Boolean variable in Ls.c. 3.Add doxygen tags in comment and return type for 'ToLower' in ShellProtocol.c.
Daryl McDaniel [Fri, 7 Mar 2014 01:05:30 +0000 (01:05 +0000)]
StdLib: Modify the memory allocation routines to not be dependent upon the internal structure of the EDK II memory pool.
StdLib/LibC/StdLib/Malloc.c
Create a private data structure, CPOOL_HEAD, which contains housekeeping information for StdLib’s memory allocation functions. An instance of this structure is prepended to every chunk of allocated memory. The structure links the allocation into a doubly-linked list and keeps track of the size of each allocation unit. This information is then available for use by the realloc function.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Daryl McDaniel <daryl.mcdaniel@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com> Reviewed-by: Erik Bjorge <erik.c.bjorge@intel.com> Reviewed-by: Rosenbaum, Lee G <lee.g.rosenbaum@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15319 6f19259b-4bc3-4df7-8a09-765794883524
Mike Maslenkin [Wed, 5 Mar 2014 08:45:13 +0000 (08:45 +0000)]
The size of platform memory above 1M is measured in kilobytes.
This patch fixes truncation of this value. Actually 0 Mb memory size was set by reason of overflow of 16 bit word caused by wrong value used.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Mike Maslenkin <mihailm@parallels.com> Reviewed-by: Elvin Li <elvin.li@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15318 6f19259b-4bc3-4df7-8a09-765794883524
Laszlo Ersek [Tue, 4 Mar 2014 08:04:13 +0000 (08:04 +0000)]
OvmfPkg: S3 Resume: pull in BootScriptExecutorDxe
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.
projects / mirror_edk2.git / log