BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2363
This patch is to fix a build tool regression issue which was introduced
by commit b8ac0b7f28.This issue caused map file lost the line of IMAGE=***.
For example,in Ovmf.map, there is no line of (IMAGE=<path to efi> ) under
each of modules item.
The path to the efi file generated by each module is written on this line
The purpose of this line is add the debug image full path.
there is no information about the module in the map file other than FVName,
it allows us to quickly know which module this part corresponds to.
In commit b8ac0b7f28,add a line ("self.BuildModules = []") in function,
but it's used to calculate the variable ModuleList in the following code.
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2270
Currently a PCD (e.g. FeaturePCD) cannot be used in a conditional
statement in a DSC/FDF file without a module in the build referencing
the PCD package DEC file.
An example implementation that to support this is to allow a [Packages]
section in the DSC file to list additional package dependencies for PCD
references in the package DSC/FDF files.
this patch is going to add the ability to have the [packages] section
defined in the DSC file
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Acked-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2118
When a packet is queued/completed for the asynchronous IO queue, the logic
to roll over to the front of the queue doesn't account for actual size of
the IO Submission/Completion queue.
This causes a device to hang due to doorbell being outside of visible
queue. An example would be if an NVMe drive only supported a queue size of
128 while the driver supports 256.
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Acked-by: Ray Ni <ray.ni@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2333
During a SetVariable () invocation, UpdateVariable () is called.
UpdateVariable () contains logic to determine whether a volatile or
non-volatile UEFI variable was set so the corresponding runtime
cache can be updated to reflect the change. The current logic simply
evaluates Variable->Volatile to determine which runtime cache should
be updated.
The problem is Variable->Volatile does not always reflect whether a
volatile variable is being set. Variable->Volatile is set to TRUE
only in the case a pre-existing variable is found in the volatile
variable store. Therefore, the value is FALSE when a new volatile
variable is written.
This change updates the logic to take this into account. If a new
variable is written successfully, the Attributes will accurately
reflect whether the variable is non-volatile. If a pre-existing
variable is modified, the Volatile field will reflect the type of
variable (Attributes are not reliable; e.g. 0x0 indicates deletion).
* Observable symptom: A volatile variable that was set successfully
might return EFI_NOT_FOUND when the variable should be found.
* The issue is a regression introduced to the variable services only
when the variable runtime cache is enabled by the following PCD
being set to TRUE:
gEfiMdeModulePkgTokenSpaceGuid.PcdEnableVariableRuntimeCache
* The issue was implemented in commit aab3b9b9a1 but the PCD was not
set to TRUE by default enabling the issue until commit e07b7d024a.
Fixes: aab3b9b9a1
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1871
This is null version of RngLib which should be used with modules that
inherit an (indirect) dependency on the RngLib class, but never actually
call RngLib APIs for consuming randomness.
To be more specific, if following components or functionalities are used
in a platform, the BaseRngLibNull should *not* be used. Instead, a non-Null
version of RngLib must be used (like BaseRngLib for IA32/X64, or future
DxeRngLibRngProtocol for all ARCHs).
- HddPasswordDxe.inf
- AES, TLS (TlsDxe.inf, TlsLib.inf), RSA_OAEP, RSA_PK1
- (If BaseRngLibNull interface ASSERTed at boot time)
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2329
XD (ExecutionDisable) feature, when turned on, allows page table
entry BIT63 set to 1 indicating the memory pointed by the page table
is disallowed to execute.
DxeIpl::CreateIdentityMappingPageTables() enables the XD when CPU
supports it.
Later DxeCore modifies the page table to set the BIT63 to protect
the stack/heap to disallow code execution in stack/heap.
UefiCpuPkg/CpuCommonFeaturesLib enables/disables the XD feature
according to PcdCpuFeaturesSetting.
When XD is disabled, GP fault is generated immediately because some
page entries have BIT63 set.
To fix this issue, this patch removes the XD feature logic from
UefiCpuPkg/CpuCommonFeaturesLib so the XD feature is only taken
care of by DxeIpl.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2315
Add directory for the Mergify YML configuration files that
provides rules and actions used to process a pull request.
* Auto commit a PR from EDK II Maintainer with 'push' label
set and all CI checks pass
* Auto close a PR from any developers without 'push' label
set and all CI checks pass.
* Auto close a PR from a non EDK II Maintainer that has
the 'push' label set.
* Post a comment to a PR that has a merge conflict.
Submitter can resolved conflicts and reopen the PR.
* Post a comment to a PR that fails PatchCheck.py
Submitter can resolve PatchCheck.py issues and
reopen the PR.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2315
Add YAML file to the package directory with the
configuration of the checks to perform during a
CI build.
Use BaseCryptLibNull and TlsLibNull for package CI
builds to reduce package build times. Enabled with
CONTINUOUS_INTEGRATION in YAML files. By default
CONTINUOUS_INTEGRATION is not defined, and the
original lib mappings are preserved.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2315
Add YAML file to the package directory with the
configuration of the checks to perform during a
CI build.
Use BaseCryptLibNull for package CI builds to reduce package
build times. Enabled with CONTINUOUS_INTEGRATION in YAML
files. By default CONTINUOUS_INTEGRATION is not defined,
and the original lib mappings are preserved.
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2315
Add use of RC_PATH define that provides the path to the resource
compiler that is typically provided in a Windows SDK. The path
changes with different Windows SDK releases. This define is set
to the WINSDK_PATH_FOR_RC_EXE environment variable. This
environment variable must be set to the path to the currently
installed resource compiler (rc.exe).
Update set_vsprefix_envs.bat to set WINSDK_PATH_FOR_RC_EXE
if a Windows SDK is detected.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Remove references to the number of submodules in the tree, as well as
reword the referring to specific submodules as "former" and "previous".
This means we won't need to keep updating the surrounding text if we
add/remove submodules.
Cc: Andrew Fish <afish@apple.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2303
Whenever a PCI device is discovered, PCI bus calls the
EDKII_DEVICE_SECURITY_PROTOCOL to authenticate it.
If the function returns success, the PCI bus allocates
the resource and installs the PCI_IO for the device.
If the function returns fail, the PCI bus skips the device.
It is similar to EFI_SECURITY_ARCH_PROTOCOL, which
is used to verify an EFI image.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Yun Lou <yun.lou@intel.com>
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
When a boot loader examines the memory map, it can see that location 0
is available memory. If it chooses to use that memory, and
PcdNullPointerDetectionPropertyMask is enabled, use of memory in page 0
will cause an exception. This does occur when running the memtest86
program.
Leaving page 0 available is for legacy support purpose. Since we have
deprecated the support of legacy, the solution is just reserving it so
that it cannot be allocated for other uses.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1885
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
In order to permit the use of compilers that only implement the small
code model [which involves the use of ADRP instructions that require
4 KB segment alignment] for generating PE/COFF binaries with a small
footprint, we patch ADRP instructions into ADR instructions while doing
the ELF to PE/COFF conversion.
As it turns out, the linker may be doing the same, but for different
reasons: there is a silicon erratum #843419 for ARM Cortex-A53 which
affects ADRP instructions appearing at a certain offset in memory, and
one of the mitigations for this erratum is to patch them into ADR
instructions at link time if the symbol reference is within -/+ 1 MB.
However, the LD linker fails to update the static relocation tables, and
so we end up with an ADR instruction in the fully linked binary, but
with a relocation entry in the RELA section identifying it as an ADRP
instruction.
Since the linker has already updated the symbol reference, there is no
handling needed in GenFw for such instructions, and we can simply treat
it as an ordinary ADR. However, since it is guaranteed to be accompanied
by an add or load instruction with a LO12 relocation referencing the same
symbol, the section offset check we apply to ADR instructions is going to
take place anyway, so we can just disregard the ADR instruction entirely.
Reported-by: Eugene Cohen <eugene@hp.com>
Suggested-by: Eugene Cohen <eugene@hp.com>
Tested-by: Eugene Cohen <eugene@hp.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Liming Gao <liming.gao@intel.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Add a PCD to govern whether to use DT or ACPI in case the
variable governing this is not found or is not valid.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
We have discussed in this thread.
https://edk2.groups.io/g/devel/topic/32205028
Before the change, TPM FW upgrade will impact TPM2 ACPI PCR value because
TPM2 ACPI HID include FW version.
This change make the measurement before TPM2 HID fixup. So, after TPM FW
upgrade, the ACPI PCR record remains the same.
Signed-off-by: Derek Lin <derek.lin2@hpe.com>
Reviewed by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2327
RAID drivers abstract their physical drives that make up
the array into a single unit, and do not supply individual
EFI_BLOCK_IO_PROTOCOL instances for each physical drive in the array.
This breaks support for the Security Storage Command Protocol,
which currently requires an EFI_BLOCK_IO_PROTOCOL to be associated
with the same device the protocol is installed on and provide
all the same parameters.
This patch remove dependency on EFI_BLOCK_IO_PROTOCOL and
allows access to Opal drive members of a RAID array.
Signed-off-by: Maggie Chu <maggie.chu@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Sets gEfiMdeModulePkgTokenSpaceGuid.PcdEnableVariableRuntimeCache
to FALSE in OvmfPkgIa32.dsc, OvmfPkgIa32X64.dsc, and OvmfPkgX64.dsc
so that when SMM_REQUIRE is TRUE, the SMM variable driver will not
use the runtime variable cache.
This is done for OvmfPkg because it currently depends upon a SMM
variable GetVariable ()implementation as a simple method to exercise
the SMM driver stack. This allows the following commands to be used
for variables such as Boot####, BootOrder, and BootNext to test SMM
timing and stability differences on the BSP (e.g. CPU#0) vs an
AP (e.g. CPU#1).
# taskset -c 0 efibootmgr
# taskset -c 1 efibootmgr
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2220
This change reduces SMIs for GetVariable () by maintaining a
UEFI variable cache in Runtime DXE in addition to the pre-
existing cache in SMRAM. When the Runtime Service GetVariable()
is invoked, a Runtime DXE cache is used instead of triggering an
SMI to VariableSmm. This can improve overall system performance
by servicing variable read requests without rendezvousing all
cores into SMM.
The runtime cache can be disabled with by setting the FeaturePCD
gEfiMdeModulePkgTokenSpaceGuid.PcdEnableVariableRuntimeCache
to FALSE. If the PCD is set to FALSE, the runtime cache will not be
used and an SMI will be triggered for Runtime Service
GetVariable () and GetNextVariableName () invocations.
The following are important points regarding the behavior of the
variable drivers when the variable runtime cache is enabled.
1. All of the non-volatile storage contents are loaded into the
cache upon driver load. This one time load operation from storage
is preferred as opposed to building the cache on demand. An on-
demand cache would require a fallback SMI to load data into the
cache as variables are requested.
2. SetVariable () requests will continue to always trigger an SMI.
This occurs regardless of whether the variable is volatile or
non-volatile.
3. Both volatile and non-volatile variables are cached in a runtime
buffer. As is the case in the current EDK II variable driver, they
continue to be cached in separate buffers.
4. The cache in Runtime DXE and SMM are intended to be exact copies
of one another. All SMM variable accesses only return data from the
SMM cache. The runtime caches are only updated after the variable I/O
operation is successful in SMM. The runtime caches are only updated
from SMM.
5. Synchronization mechanisms are in place to ensure the runtime cache
content integrity with the SMM cache. These may result in updates to
runtime cache that are the same in content but different in offset and
size from updates to the SMM cache.
When using SMM variables with runtime cache enabled, two caches will now
be present.
1. "Runtime Cache" - Maintained in VariableSmmRuntimeDxe. Used to service
Runtime Services GetVariable () and GetNextVariableName () callers.
2. "SMM Cache" - Maintained in VariableSmm to service SMM GetVariable ()
and GetNextVariableName () callers.
a. This cache is retained so SMM modules do not operate on data outside
SMRAM.
Because a race condition can occur if an SMI occurs during the execution
of runtime code reading from the runtime cache, a runtime cache read lock
is introduced that explicitly moves pending updates from SMM to the runtime
cache if an SMM update occurs while the runtime cache is locked. Note that
it is not expected a Runtime services call will interrupt SMM processing
since all CPU cores rendezvous in SMM.
It is possible to view UEFI variable read and write statistics by setting
the gEfiMdeModulePkgTokenSpaceGuid.PcdVariableCollectStatistics FeaturePcd
to TRUE and using the VariableInfo UEFI application in MdeModulePkg to dump
variable statistics to the console. By doing so, a user can view the number
of GetVariable () hits from the Runtime DXE variable driver (Runtime Cache
hits) and the SMM variable driver (SMM Cache hits). SMM Cache hits for
GetVariable () will occur when SMM modules invoke GetVariable ().
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2220
The current VariableInfo application only checks for variable
statistics from SMM if the variable information entries are
not present in the UEFI System Configuration table as published
by the DXE UEFI variable driver (VariableRuntimeDxe).
This change first checks for variable information entries in the
UEFI System Configuration but always checks for entries in SMM
as well. If the SMM variable driver is not present, an instance of
EFI_SMM_VARIABLE_PROTOCOL will not be found and the search for
SMM variable statistics will be aborted (an SW SMI to get variable
statistics will not be triggered).
In the case variable statistics are provided by both a Runtime DXE
driver (e.g. VariableSmmRuntimeDxe) and a SMM driver (VariableSmm),
this change will clearly identify statistics from each respective
driver.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
This change moves the following functions into a dedicated file
so they may be used in other variable files as needed. These are
commonly needed for basic variable data structure parsing
operations. The functions are grouped together in VariableParsing.c
to support cohesiveness for these operations in the file.
Furthermore, it reduces the overall size of the common Variable.c
file.
* DataSizeOfVariable ()
* FindVariableEx ()
* GetEndPointer ()
* GetNextVariablePtr ()
* GetStartPointer ()
* GetVariableDataOffset ()
* GetVariableDataPtr ()
* GetVariableHeaderSize ()
* GetVariableNamePtr ()
* GetVariableStoreStatus ()
* GetVendorGuidPtr ()
* IsValidVariableHeader ()
* NameSizeOfVariable ()
* SetDataSizeOfVariable ()
* SetNameSizeOfVariable ()
* UpdateVariableInfo ()
* VariableCompareTimeStampInternal ()
* VariableServiceGetNextVariableInternal ()
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Before called by GetBufferForValue(), Value has already been called
function IsTypeInBuffer to make sure the value must be buffer type.
So GetBufferForValue can not return NULL.
This commit adds ASSERT to assume (GetBufferForValue (&Value) is not
NULL.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Upgrade openssl from 1.1.1b to 1.1.1d.
Something needs to be noticed is that, there is a bug existing in the
released 1_1_1d version(894da2fb7ed5d314ee5c2fc9fd2d9b8b74111596),
which causes build failure. So we switch the code base to a usable
version, which is 2 commits later than the stable tag.
Now we use the version c3656cc594daac8167721dde7220f0e59ae146fc.
This log is to fix the build failure.
https://bugzilla.tianocore.org/show_bug.cgi?id=2226
Besides, the absense of "DSO_NONE" in dso_conf.h causes build failure
in OvmfPkg. So update process_files.pl to generate information from
"crypto/include/internal/dso_conf.h.in".
shm.h and utsname.h are added to avoid GCC build failure.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
MpInitLib sets X2ApicEnable in two places.
1. CollectProcessorCount()
This function is called when MpInitLibInitialize() hasn't been
called before.
It sets X2ApicEnable and later in the same function it configures
all CPUs to operate in X2 APIC mode.
2. MpInitLibInitialize()
The X2ApicEnable setting happens when this function is called in
second time. But after that setting, no code consumes that flag.
With the above analysis and with the purpose of simplifying the code,
the X2ApicEnable in #1 is changed to local variable and the #2 can be
changed to remove the setting of X2ApicEnable.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Today's logic sets X2ApicEnable flag in each AP's initialization
path when InitFlag == ApInitConfig.
Since all CPUs update the same global data, a spin-lock is used
to avoid modifications from multiple CPUs happen at the same time.
The spin-lock causes two problems:
1. Potential performance downgrade.
2. Undefined behavior when improper timer lib is used.
For example we saw certain platforms used AcpiTimerLib from
PcAtChipsetPkg and that library depends on retrieving PeiServices
from idtr. But in fact AP's (idtr - 4) doesn't point to
PeiServices.
The patch simplifies the code to let BSP set the X2ApicEnable flag so
the spin-lock acquisition from AP is not needed any more.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
RequestMap is used but not Initialized.
RequestMap is called by UhciMapUserRequest, in which RequestMap(Map)
is called by IoMmuMap, and is finally called by IoMmu->Map.
We can not assume RequestMap is given an initial value at any step.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Map is used but not Initialized.
Map is called by IoMmuMap, in which Mapping(Map) is called by IoMmu->Map.
We can not assume Map is given an initial value at any step.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Foreground and background color are saved in a single byte.
Bits 0..3 are the foreground color and bits 4..6 are the background color.
If the Private->Attribute defined correctly, (Private->Attribute >> 4)
must be less than 8.
This commit uses ASSERT to assume "Attribute >> 4" is less than 8.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
IndexTable->Length is used as index in array IndexTable->Index[].
So IndexTable->Length needs to be checked, which should be less than
the array size.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The ACPI specification, version 6.3, January 2019,
defines the Named Object Encoding for ExternalOp
in section '20.2.5.2 Named Objects Encoding'.
This patch adds the definition for ExternalOp to
the list of Primary Opcode definitions.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2295
The current implementation of the FileHandleGetFileName() function
assumes that the Root directory always has the FileName '\0'.
However, the only requirement the UEFI specification defines is that
a prepended '\\' must be supported to access files and folders
relative to the Root directory.
This patch removes this assumption and supports constructing valid
paths for any value of FileName for the Root Directory.
In practice, this fixes compatibility issues with File System drivers
that report '\\' as the FileName of the Root directory, which
currently is both generating an invalid path ("\\\\") and resulting
in an EFI_NOT_FOUND result from the CurrentHandle->Open() call.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Marvin Haeuser <mhaeuser@outlook.de>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Using the inet_pton() function that we imported in the previous patches,
recognize if "HostName" is an IP address literal, and then parse it into
binary representation. Passing the latter to OpenSSL for server
certificate validation is important, per RFC-2818
<https://tools.ietf.org/html/rfc2818#section-3.1>:
> In some cases, the URI is specified as an IP address rather than a
> hostname. In this case, the iPAddress subjectAltName must be present in
> the certificate and must exactly match the IP in the URI.
Note: we cannot use X509_VERIFY_PARAM_set1_ip_asc() because in the OpenSSL
version that is currently consumed by edk2, said function depends on
sscanf() for parsing IPv4 literals. In
"CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c", we only provide an
empty -- always failing -- stub for sscanf(), however.
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Sivaraman Nainar <sivaramann@amiindia.co.in>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=960
CVE: CVE-2019-14553
Suggested-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
For TianoCore BZ#1734, StdLib has been moved from the edk2 project to the
edk2-libc project, in commit 964f432b9b ("edk2: Remove AppPkg, StdLib,
StdLibPrivateInternalFiles", 2019-04-29).
We'd like to use the inet_pton() function in CryptoPkg. Resurrect the
"inet_pton.c" file from just before the StdLib removal, as follows:
$ git show \
964f432b9b0a^:StdLib/BsdSocketLib/inet_pton.c \
> CryptoPkg/Library/BaseCryptLib/SysCall/inet_pton.c
The inet_pton() function is only intended for the DXE phase at this time,
therefore only the "BaseCryptLib" instance INF file receives the new file.
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Sivaraman Nainar <sivaramann@amiindia.co.in>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=960
CVE: CVE-2019-14553
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
In a later patch in this series, we're going to resurrect "inet_pton.c"
(originally from the StdLib package). That source file has a number of
standard C and BSD socket dependencies. Provide those dependencies here:
- The header files below will simply #include <CrtLibSupport.h>:
- arpa/inet.h
- arpa/nameser.h
- netinet/in.h
- sys/param.h
- sys/socket.h
- EAFNOSUPPORT comes from "StdLib/Include/errno.h", at commit
e2d3a25f1a31; which is the commit immediately preceding the removal of
StdLib from edk2 (964f432b9b).
Note that the other error macro, which we alread #define, namely EINVAL,
has a value (22) that also matches "StdLib/Include/errno.h".
- The AF_INET and AF_INET6 address family macros come from
"StdLib/Include/sys/socket.h".
- The NS_INT16SZ, NS_INADDRSZ and NS_IN6ADDRSZ macros come from
"StdLib/Include/arpa/nameser.h".
- The "u_int" and "u_char" types come from "StdLib/Include/sys/types.h".
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Sivaraman Nainar <sivaramann@amiindia.co.in>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=960
CVE: CVE-2019-14553
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
According to the ISO C standard, strchr() is a function. We #define it as
a macro. Unfortunately, our macro evaluates the first argument ("str")
twice. If the expression passed for "str" has side effects, the behavior
may be undefined.
In a later patch in this series, we're going to resurrect "inet_pton.c"
(originally from the StdLib package), which calls strchr() just like that:
strchr((xdigits = xdigits_l), ch)
strchr((xdigits = xdigits_u), ch)
To enable this kind of function call, turn strchr() into a function.
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Sivaraman Nainar <sivaramann@amiindia.co.in>
Cc: Xiaoyu Lu <xiaoyux.lu@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=960
CVE: CVE-2019-14553
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
For now, PlatformRecovery doesn't work if OsIndications variable
doesn't exist, which is wrong.
According to the UEFI specification section 3.4.1 and 3.4.2, if
processing of BootOrder does not result in success, the OsRecovery
and PlatformRecovery options should still be processed regardless of
the existence of the OsIndications variable.
Therefore, update the code to check PcdPlatformRecoverySupport instead
of the value of OsIndications variable (PlatformRecovery) to fix
this issue.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Walon Li <walon.li@hpe.com>
Signed-off-by: Sunny Wang <sunnywang@hpe.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Acked-by: Jian J Wang <jian.j.wang@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2312
This patch is for fixing unexpected system hang during S3 unlock process.
FatPei driver maintained and updated internal BlockIo devices list
when there is new BlockIo PPI has installed, and it relied on BlockIo PPI
service to get data from devices. Because BlockIo Ppi leverage
NvmExpressPei Ppi to transit Nvm command to device, we should make sure
NvmePassThruPpi installed before BlockIo PPI.
Signed-off-by: Maggie Chu <maggie.chu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
This patch fixes a problem introduced by commit
61bb6eeb4d.
The PcdSnpCreateExitBootServicesEvent is not guaranteed to be FixedAtBuild,
so use PcdGetBool() to supports both fixed and patchable PCD.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Signed-off-by: Siyuan Fu <siyuan.fu@intel.com>
Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2310
When target FV 99% used and only few bytes space left,
SplitFspBin.py may crash with below error:
File "SplitFspBin.py", line 457, in ParseFv
ffshdr = EFI_FFS_FILE_HEADER.from_buffer (self.FvData, offset)
ValueError: Buffer size too small
(40960 instead of at least 40968 bytes)
It was because the offset used by FFS_HEADER parser out of bounds.
It should stop parsing when offset equal or larger than
(buffer size - FFS_HEADER size).
This patch also fixed another crash issue when running script with
Python 3.x and no input parameter given:
File "SplitFspBin.py", line 868, in main
if args.which in ['rebase', 'split', 'genhdr', 'info']:
AttributeError: 'Namespace' object has no attribute 'which'
Test:
1. Ran script with both py2 and py3 with no input and no crash observed.
2. Compare the script result before and after the patch are identical.
Cc: Maurice Ma <maurice.ma@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
1. Add WIN_HOST_BUILD macro check for CLANG9 tool chain
build -p EmulatorPkg\EmulatorPkg.dsc -a IA32 -DWIN_HOST_BUILD=TRUE -t CLANG9
build -p EmulatorPkg\EmulatorPkg.dsc -a X64 -DWIN_HOST_BUILD=TRUE -t CLANG9
2. Append CLANG CC and LINK flags to generate windows HOST.
3. Fix WinHost issue to call GetProcessAffinityMask() API.
The input parameter should be UINTN pointer instead of UINT32 pointer.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
CLANG9 generated PE image exposes below two issues.
1. SectionSize is used to copy PE section data. It should be smaller than
section raw size.
2. The real data is required to be copied. So, copy the min size of
VirtualSize and SizeOfRawData.
Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2255
Update UefiCpuPkg.dsc to guarantee all libraries and
modules are always built. Add the following components.
* UefiCpuPkg/ResetVector/Vtf0/Bin/ResetVector.inf
* UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.inf
ResetVector.inf is a binary INF, so no source builds are
triggered from adding this line. However, a build with
this component does verify the contents of the INF file.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Currently some tests check the value of SOURCE_DEBUG_ENABLE, and some
tests check if it's defined or not. Additionally, in UefiPayloadPkg as
well as some other trees, we define it as FALSE in the .dsc file.
This patch changes all of the Ovmf platforms to explicitly define it as
FALSE by default, and changes all of the checks to test if the value is
TRUE.
Signed-off-by: Peter Jones <pjones@redhat.com>
Message-Id: <20190920184507.909884-1-pjones@redhat.com>
[lersek@redhat.com: drop Contributed-under line, per TianoCore BZ#1373]
[lersek@redhat.com: replace "!= TRUE" with more idiomatic "== FALSE"]
Cc: Andrew Fish <afish@apple.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Peter Jones <pjones@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
The SRAT generator uses the configuration manager protocol
to obtain the affinity information for the GICC, GIC ITS,
Memory, Generic Initiator, etc. and generates the SRAT table.
The table generator supports ACPI 6.3, SRAT table revision 3.
The ACPI and PCI device handles of the Generic Initiator
Affinity structures are represented using tokens. The
generator invokes the configuration manager protocol
interfaces and requests for objects referenced by tokens
to get the device handle information.
The Configuration Manager object definition for the GICC has
been updated to include the Proximity Domain, Clock Domain
and associated flag information. Similarly the Configuration
Manager object for the GIC ITS has been updated to include
the Proximity Domain information. These changes should not
impact any existing implementations as the new fields have
been added towards the end of the Configuration Manager
Objects.
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Patch addresses Bugzilla #1974.
During ExitBootServices stage, drivers should not call any
functions known to use Memory Allocation Services. One of such
functions (as per UEFI spec) is UNDI->Shutdown().
Since UNDI drivers during ExitBootServices phase are expected
to put the adapter to such a state that it will not perform any DMA
operations, there is no need to interface UNDI by SNP driver during
that phase.
Finally, since ExitBootServices event notification function in SNP
only calls UNDI->Shutdown() and Stop() functions, there is no need
to create this event at all. Adding PCD to control creation of event
reacting to ExitBootServices() call so that systems with UNDIs relying
on SNP to call their Shutdown() and Stop() can still work.
Change-Id: Idd76f26d2e8ff7cf88b2d75e2d524c74211f2e89
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Maciej Rabeda <maciej.rabeda@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Add support for allocating aligned pages at an alignment higher
than 4K. The new function allocated memory taking into account
the padding required and then frees up unused pages before mapping
it.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
While allocating pages aligned at an alignment higher than
4K, allocate memory taking into consideration the padding
required for that alignment. The calls to free pages takes
care of this already.
Signed-off-by: Ashish Singhal <ashishsingha@nvidia.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
commit a7e2d20193 introduces the code to
get PcdTpm2AcpiTableRev in the driver entry point. This PCD is designed as
DynamicHii or DynamicHiiEx PCD. So, this PCD depends on Variable service.
To make sure PcdTpm2AcpiTableRev value be got, add Variable service as Depex.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Chao Zhang <chao.b.zhang@intel.com>
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: jiewen Yao <jiewen.yao@intel.com>
When c/h file use macro after #include, for example,
In this case, GenMake is not able to create a healthy dependency for the c
file. GenMake used to add $(FORCE_REBUILD) dependency in the c file, this
guarantee the c file is always compiled in incremental build. But, this
function is broken since 05217d210e which
enable /MP for MSVC compiler, in order to compile multiple c files in one
command multi-processing. The fix here is adding '$(FORCE_REBUILD)' back to
retain the original function.
Line number 1728 and 978 are the code pieces which handle this logic.
Signed-off-by: Derek Lin <derek.lin2@hpe.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
An extra 's' slipped into the 'processing' word.
Drop it to fix the typo.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
An extra 's' slipped into the FvIsBeingProcessed function
name. Drop it to fix the typo.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2266
Similar to what we now do for OVMF, we need to consider the possibility
that PlatformBootManagerWaitCallback () may be called with a
PcdPlatformBootTimeOut that was set to zero, in which case the call should
simply return.
We also change the initial timeout variable name to make the code explicit.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20191014150311.16740-3-pete@akeo.ie>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2266
Independently of how we decide to address other aspects of the regression
introduced with commit 2de1f611be, it doesn't
make much sense to call for a progress update if PcdPlatformBootTimeOut is
zero.
PcdPlatformBootTimeOut 0, which is the cause of the bug (division by zero)
should be considered to indicate that a platform is not interested in
displaying a progress report, so we alter PlatformBootManagerWaitCallback
to behave that way.
We also change one variable name to make the code more explicit.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Message-Id: <20191014150311.16740-2-pete@akeo.ie>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2266
Commit 2de1f611be introduced a regression
whereas platforms that did set PcdPlatformBootTimeOut to 0 are now getting
an unexpected call to PlatformBootManagerWaitCallback().
This patch also ensures that, if PcdPlatformBootTimeOut is 0xFFFF we don't
call PlatformBootManagerWaitCallback() with a zero argument as doing so
would produce an unwarranted jump to full progress completion which is
likely to throw off users.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>
- If a platform boots such that the boot CPU count is smaller than
PcdCpuMaxLogicalProcessorNumber, then the platform cannot use the "fast
AP detection" logic added in commit 6e1987f19a. (Which has been
documented as a subset of use case (2) in the previous patch.)
Said logic depends on the boot CPU count being equal to
PcdCpuMaxLogicalProcessorNumber. If the equality does not hold, the
platform either has to wait too long, or risk missing APs due to an
early timeout.
- The platform may not be able to use the variant added in commit
0594ec417c either. (Which has been documented as use case (1) in the
previous patch.)
See commit 861218740d. When OVMF runs on QEMU/KVM, APs may check in
with the BSP in arbitrary order, plus the individual AP may take
arbitrarily long to check-in. If "NumApsExecuting" falls to zero
mid-enumeration, APs will be missed.
Allow platforms to specify the exact boot CPU count, independently of
PcdCpuMaxLogicalProcessorNumber. In this mode, the BSP waits for all APs
to check-in regardless of timeout. If at least one AP fails to check-in,
then the AP enumeration hangs forever. That is the desired behavior when
the exact boot CPU count is known in advance. (A hung boot is better than
an AP checking-in after timeout, and executing code from released
storage.)
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The last parameter of ReserveResourceInGcd() is "ImageHandle", forwarded
in turn to gDS->AllocateMemorySpace() or gDS->AllocateIoSpace() as "owner"
image handle.
But BlDxeEntryPoint() passes "SystemTable" as "ImageHandle".
Compilers have not flagged it because EFI_HANDLE (the type of
"ImageHandle") is unfortunately specified as (VOID*), and
(EFI_SYSTEM_TABLE*) converts to (VOID*) silently.
Hand the entry point function's "ImageHandle" parameter to
ReserveResourceInGcd(). This fixes an actual bug.
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
(This patch is unrelated to the rest of this series; its purpose is to
enable building the UefiPayloadPkg DSC files with GCC.)
When building "UefiPayloadPkg/UefiPayloadPkgIa32.dsc" with GCC48 for the
DEBUG target, the compiler reports that "Entry32" may be used
uninitialized in ParseAcpiInfo(), in the XSDT branch.
Code inspection proves the compiler right. In the XSDT branch, the code
from the RSDT branch must have been duplicated, and "Entry32" references
were replaced with "Entry64" -- except where "MmCfgHdr" is assigned.
Fix this bug by introducing a helper variable called "Signature", so that
we have to refer to "Entry32" or "Entry64" only once per loop body.
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Guo Dong <guo.dong@intel.com>
Cc: Maurice Ma <maurice.ma@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Guo Dong <guo.dong@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
The FvHasBeenProcessed() and FvIsBeingProcesssed() functions make sure
that every firmware volume is processed only once (every driver in every
firmware volume should be discovered only once). For this, the functions
use a linked list.
In MdeModulePkg's DXE Core and SMM Core, the key used for identifying
those firmware volumes that have been processed is the EFI_HANDLE on which
the DXE or SMM firmware volume protocol is installed. In the
StandaloneMmPkg core however, the key is the address of the firmware
volume header; that is, it has type (EFI_FIRMWARE_VOLUME_HEADER*).
(EFI_FIRMWARE_VOLUME_HEADER*) has nothing to do with EFI_HANDLE.
EFI_HANDLE just happens to be specified as (VOID*), and therefore the
conversion between (EFI_FIRMWARE_VOLUME_HEADER*) and EFI_HANDLE is silent.
(The FvHasBeenProcessed() and FvIsBeingProcesssed() functions were likely
copied verbatim from MdeModulePkg's DXE Core and/or the SMM Core, and not
flagged by the compiler in StandaloneMmPkg due to UEFI regrettably
specifying EFI_HANDLE as (VOID*), thereby enabling the above implicit
conversion.)
We should not exploit this circumstance. Represent the key type faithfully
instead.
This is a semantic fix; there is no change in operation.
Cc: Achin Gupta <achin.gupta@arm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Supreeth Venkatesh <supreeth.venkatesh@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Achin Gupta <achin.gupta@arm.com>
The EDK 1 Shell (available at <https://github.com/tianocore/edk-Shell>)
has a bug in its EFI_SHELL_ENVIRONMENT2.Execute() implementation that
edk2's UefiShellLib has no choice but to work around.
Improve the explanation in the code. Also, document the implicit
EFI_HANDLE -> (EFI_HANDLE*) conversion, which happens implicitly after
dereferencing ParentHandle, with an explicit cast.
In practice, this patch is a no-op.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
In the FileBufferSave() function, we invoke ShellCloseFile() if "Directory
Can Not Be Saved".
The ShellCloseFile() function takes a (SHELL_FILE_HANDLE*) parameter
called "FileHandle", and correctly passes the de-referenced (*FileHandle)
to EFI_SHELL_CLOSE_FILE, which takes a SHELL_FILE_HANDLE.
However, FileBufferSave() passes SHELL_FILE_HANDLE to ShellCloseFile(),
not the expected (SHELL_FILE_HANDLE*). Correct it.
This fixes an actual bug that has remained hidden for two reasons:
- pointer-to-VOID converts from/to any pointer-to-object type silently,
- the bug is on an error path which has likely never fired in practice.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
The TouchFileByHandle() and IsDirectoryEmpty() functions are passed
SHELL_FILE_HANDLE parameters, and they use those parameters correctly.
However, their parameter lists say EFI_HANDLE.
Spell out the right type in the parameter lists.
In practice, this change is a no-op (because, quite regrettably, both
EFI_HANDLE and SHELL_FILE_HANDLE are specified to be typedefs of (VOID*)).
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
The UefiShell*CommandsLib instances have constructor functions that do
something like:
gHiiHandle = HiiAddPackages (...);
...
ShellCommandRegisterCommandName (..., gHiiHandle, ...);
and destructor functions that implement the following pattern:
HiiRemovePackages (gHiiHandle);
The -- semantic, not functional -- problem is that "gHiiHandle" is
declared with type EFI_HANDLE, and not EFI_HII_HANDLE, in all of these
library instances, even though HiiAddPackages() correctly returns
EFI_HII_HANDLE, and HiiRemovePackages() takes EFI_HII_HANDLE.
Once we fix the type of "gHiiHandle", it causes sort of a butterfly
effect, because it is passed around widely. Track down and update all of
those locations.
The DynamicCommand lib instances use a similar pattern, so they are
affected too.
NOTE: in practice, this patch is a no-op, as both EFI_HII_HANDLE and
EFI_HANDLE are typedefs to (VOID*). However, we shouldn't use EFI_HANDLE
where semantically EFI_HII_HANDLE is passed around.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
The ShellCommandRunConnect() function passes EFI_HANDLE -- (VOID*) --
objects to ConvertAndConnectControllers(), and
ConvertAndConnectControllers() passes those to gBS->OpenProtocol().
Accordingly, ConvertAndConnectControllers() should specify EFI_HANDLE
parameter types, not (EFI_HANDLE*) -- (VOID**) -- types.
This typo is masked because (VOID*) converts to and from any
pointer-to-object type silently.
Note that functionally speaking there is no problem, so this patch does
not change beavior, only cleans up the code.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
similarly to gBS->RegisterProtocolNotify(). We should pass the address of
an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT
just happens to be specified as (VOID*), and has nothing to do with the
registration.
This change is a no-op in practice; it's a semantic improvement.
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Jian Wang <jian.j.wang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
an (EFI_HANDLE*) as first parameter, the
UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
first parameter.
These are actual bugs. They must have remained hidden until now because
they are all in Unload() functions, which are probably exercised
infrequently. Fix the UninstallMultipleProtocolInterfaces() calls.
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Jian Wang <jian.j.wang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jiewen Yao <Jiewen.yao@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
In the following call tree:
PlatformInit ()
mInstalledPackages = HiiAddPackages ()
GopInstalled ()
PopulateForm (PackageList = mInstalledPackages)
CreateResolutionOptions (PackageList)
HiiSetString (PackageList
HiiUpdateForm (PackageList)
PlatformDxe passes around an EFI_HII_HANDLE that (a) originates from
HiiAddPackages() and (b) is ultimately passed to HiiSetString() and
HiiUpdateForm(). The intermediate functions PopulateForm() and
CreateResolutionOptions() however take that parameter as an
(EFI_HII_HANDLE*).
There is no bug in practice (because the affected functions never try to
de-reference the "PackageList" parameter, they just pass it on), but the
function prototypes are semantically wrong. Fix that.
This could remain hidden so long because pointer-to-VOID silently converts
to/from any pointer-to-object type, and the UEFI spec mandates that
EFI_HII_HANDLE be a typedef to (VOID*).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
The SignalEvent() boot service takes an EFI_EVENT, not an (EFI_EVENT*).
Fix the call in the notification function of
"EFI_SIMPLE_NETWORK_PROTOCOL.WaitForPacket".
This is an actual bug. The reason it's never been triggered is likely that
the "SNP.WaitForPacket" event is rarely waited for by applications -- edk2
itself has zero instances of that, for example.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
an (EFI_HANDLE*) as first parameter, the
UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
first parameter.
This is an actual bug. It must have remained hidden until now because it's
on an error path. Fix the UninstallMultipleProtocolInterfaces() call.
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@arm.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
The SockFreeFoo() callback function for NetbufFromExt() has to match the
NET_VECTOR_EXT_FREE prototype, which takes a (VOID*) as callback argument
(Arg). EFI_EVENT has nothing to do with NET_VECTOR_EXT_FREE. Fix the
SockFreeFoo() parameter list.
This change is a no-op in practice.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
Both NetLibDestroyServiceChild() and EFI_SERVICE_BINDING_DESTROY_CHILD
take an EFI_HANDLE for the "ChildHandle" parameter, not an (EFI_HANDLE*).
This patch fixes a real bug.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
Both the "ControllerHandle" parameter of CloseProtocol() and the "Handle"
parameter of UninstallMultipleProtocolInterfaces() have type EFI_HANDLE,
not (EFI_HANDLE*).
This patch fixes actual bugs. The issues have been dormant likely because
they are on error paths. (Or, in case of TlsAuthConfigDxe, because the
driver is unloaded likely very infrequently.)
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
NetLibGetSnpHandle() returns an EFI_HANDLE, not an (EFI_HANDLE*).
NetLibGetMacAddress() only uses the return value ("SnpHandle") for a
NULL-check. Fix the type of "SnpHandle".
This patch is a no-op.
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
The HandleProtocol() boot service takes an EFI_HANDLE, not an
(EFI_HANDLE*). Remove the bogus cast in the
InternalImageHandleToFvHandle() function.
This is a semantic cleanup; there is no change in behavior.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
The BootScriptInsert() and BootScriptLabel() functions take the in/out
parameter "Position" as (EFI_S3_BOOT_SCRIPT_POSITION*), and pass it to
S3BootScriptMoveLastOpcode() and S3BootScriptLabel(), respectively.
The callees take the in/out parameter "Position" as (VOID**). Add explicit
casts for clarity.
There is no change in functionality.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The SmiHandlerRegister() function explicitly casts "SmiHandler" (of type
(SMI_HANDLER*)) to EFI_HANDLE, when outputting "DispatchHandle".
Apply the same cast in the counterpart function SmiHandlerUnRegister(),
which compares multiple "SmiHandler"s against the input "DispatchHandle".
This is a semantic cleanup; there is no functional change.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Unlike the InstallMultipleProtocolInterfaces() boot service, which takes
an (EFI_HANDLE*) as first parameter, the
UninstallMultipleProtocolInterfaces() boot service takes an EFI_HANDLE as
first parameter.
These are actual bugs. They must have remained hidden until now because
they are on error paths. Fix the UninstallMultipleProtocolInterfaces()
calls.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Clean up two issues around FindFileEx():
- The "AprioriFile" parameter's type differs between the function
declaration and the function definition. The correct type is
(EFI_PEI_FILE_HANDLE*).
- "FfsFileHeader" has type (EFI_FFS_FILE_HEADER*); for clarity, we should
cast it explicitly to EFI_PEI_FILE_HANDLE when assigning it to
(*AprioriFile).
This is a semantic cleanup, there is no functional change.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The PI spec (v1.7) correctly specifies "EFI_RUNTIME_EVENT_ENTRY.Event" in
natural language, but the field type in the structure definition itself is
wrong -- it should be EFI_EVENT, not (EFI_EVENT*).
This spec bug is likely unfixable for compatibility reasons, and so edk2
works it around already. We should clearly document the workaround.
Functionally, this patch is a no-op.
(I've also requested a non-normative (informative) clarification for the
PI spec: <https://mantis.uefi.org/mantis/view.php?id=2017>.)
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
The HiiConstructConfigHdr() function takes the "DriverHandle" parameter in
order to fetch the device path from it, and then turn the device path into
PATH routing information.
The HiiConstructConfigHdr() function is called from
VariableCleanupHiiExtractConfig(), which is only installed when "Type" is
"VarCleanupManually" in PlatformVarCleanup().
In that case, we create "Private->DriverHandle" as a new handle, and
install "mVarCleanupHiiVendorDevicePath" on it. Then we pass
"Private->DriverHandle" to HiiAddPackages(), which consumes the device
path for routing purposes.
It follows that the "DriverHandle" argument passed to
HiiConstructConfigHdr() should be the same driver handle, for matching
routing.
Currently we pass "Private->HiiHandle", which is clearly a typo, because
it is the return value of HiiAddPackages(), and stands for the published
HII package list.
Therefore this patch addresses an actual bug.
The typo has not been flagged by compilers because the UEFI spec
regrettably defines both EFI_HANDLE and EFI_HII_HANDLE as (VOID*).
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
EfiCreateProtocolNotifyEvent() takes a (VOID**) for "Registration",
similarly to gBS->RegisterProtocolNotify(). We should pass the address of
an actual pointer-to-VOID, and not the address of an EFI_EVENT. EFI_EVENT
just happens to be specified as (VOID*), and has nothing to do with the
registration.
The same applies to gMmst->MmRegisterProtocolNotify().
"mFtwRegistration", "mFvRegistration", and "mFvbRegistration" are used for
nothing else.
This change is a no-op in practice; it's a semantic improvement.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
GetModuleInfoFromHandle() takes an EFI_HANDLE -- (VOID*) -- as first
parameter, but InsertFpdtRecord() passes (EFI_HANDLE*) -- (VOID**).
(VOID**) converts silently to (VOID*), which is why the wrong cast is
masked.
Note that the *value* that is passed is alright -- therefore this patch
does not change behavior --, it's just semantically wrong to pass an
(EFI_HANDLE*) where an EFI_HANDLE is expected.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
EFI_REGISTER_KEYSTROKE_NOTIFY and EFI_UNREGISTER_KEYSTROKE_NOTIFY require
the notification handle to have type (VOID*). The notification handle has
nothing to do with the EFI_HANDLE type.
This change is a semantic fix; functionally, it's a no-op.
Cc: Andrew Fish <afish@apple.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
The 3rd and 4th parameters of the CloseProtocol() call are wrong.
Given that we're not dissociating a child controller from a parent
controller (= closing a BY_CHILD_CONTROLLER open), but closing a BY_DRIVER
open, the 4th parameter (ControllerHandle) should equal the 1st parameter
(Handle).
It's unclear why this code hasn't crashed before.
Note that the patch doesn't fix the underlying driver model bug. I don't
understand what the loop in MmcDriverBindingStop() attempts to do. Is this
driver supposed to be a bus driver? It seems to create new handles, and to
append device path nodes. But it doesn't set up proper parent/child
protocol opens, and it doesn't close them.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
- The 2nd parameter of EFI_SERVICE_BINDING_CREATE_CHILD is:
IN OUT EFI_HANDLE *ChildHandle
- The 2nd parameter of EFI_SERVICE_BINDING_DESTROY_CHILD is:
IN EFI_HANDLE ChildHandle
Fix the DestroyChild() call in TcpFastbootTransportStop().
This is an actual bugfix; I don't know why the current code doesn't crash.
Perhaps the function is never reached in practice? (It could be tied to an
error path.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
This patch is unrelated to the rest of the series; it just makes sure that
"EmbeddedPkg/EmbeddedPkg.dsc" builds for all platforms advertised in
SUPPORTED_ARCHITECTURES (in particular, X64).
No functional changes.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The existing loop is set to call PlatformBootManagerWaitCallback every
second except the last one. We believe this is a mistake as it prevents
the called code from performing timeout expiration tasks such as, for
instance, ensuring that the last segment of a progress bar is displayed
before continuing (which is a current issue for the RPi3 platform).
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
While looking at encoding and line ending errors, I found this file
in fact simply points to a sourceforge page which no longer exists.
Since there is nothing more to say than "this is an import of
libfdt", let's just delete it.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2232
Commit 0075ab2cec introduced an issue that causes an exception
when multiple workspace packages paths are specified. For example,
if edk2-platforms is used, the root directory will contain an edk
and edk2-platforms directory representing the respective
repositories.
In GenMake, the path to the package DEC file for a module is
discovered by getting the relative path of the INF to the
workspace root directory. Each directory in the relative path
is incrementally joined to the WORKSPACE directory. The file
list in the joined path is searched for a DEC file.
As an example, if the build command is used on a package outside
the edk2 repository, the INF file path is relative to the
edk2-platforms directory not edk2. This causes directory paths
to be built that do not exist. Commit 0075ab2cec replaced the
os.path.exists() call with a try except block that always fails
when os.listdir() is invoked to enumerate the list of files in
the built directory path on packages outside edk2.
This commit restores the original conditional statement which
avoids calling os.listdir() with an invalid directory path.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2216
This patch is going to fix the lib order in static_library_files.lst.
This issue is introduced by commit 673d09a2dd.
Before 673d09a2dd, build tool apply build rule for the module's library
firstly and then apply build rule for module itself. Now, build tool
apply build rule for module self and then for its library. That behavior
impact the lib order in static_library_files.lst.
This patch is to call module's LibraryAutoGenList function
explicitly, where the applying build rule action for
library is triggered.
Cc: Liming Gao <liming.gao@intel.com>
Cc: dann frazier <dann.frazier@canonical.com>
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Tested-by: dann frazier <dann.frazier@canonical.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2218
There is a bug in current driver code that makes
it impossible for it to work with devices that
only work in legacy speed mode since the function
EmmcSwitchToHighSpeed will return with EFI_INVALID_PARAMETER
for such bus mode. Since the logic in that function will
work well for SdMmcMmcLegacy this patch just allows
to call this function with SdMmcMmcLegacy bus mode.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Marcin Wojtas <mw@semihalf.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2218
SD specification recommends switching card bus timing before
switching bus timing in controller. Emmc driver used to do
this switch other way around. This commit adds controller
timing switch in EmmcSwitchBusTiming function to enforce this
order and removes all controller timing programming from
EmmcSwitchToXXX functions.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Marcin Wojtas <mw@semihalf.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2218
Stopping the SD clock before switching host controller
bus timing is only necessary if preset value enable is
set in host controller. Code that performs switch to
HS200 doesn't check this condition right now and we also
don't do the SD clock stop before any other bus timing switch
in host controller. Since the driver is generally not ready to support
host controller with preset value enable set we removed this
code.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Hao A Wu <hao.a.wu@intel.com>
Tested-by: Marcin Wojtas <mw@semihalf.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1039
Current implementation not checks system mode before using
PAGE_TABLE_LIB_PAGING_CONTEXT.ContextData.X64 or
PAGE_TABLE_LIB_PAGING_CONTEXT.ContextData.Ia32. This patch check the
mode before using the correct one.
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
EBC compiler doesn't support C11 static_assert macro.
So, define STATIC_ASSERT as empty to pass EBC arch build.
STATIC_ASSERT macro is introduced @204ae9da230ecbf0910c21acac7aa5d5e8cbb8d0
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
There is no sourceX offset in case when
Configure->PixelFormat == PixelBlueGreenRedReserved8BitPerColor.
We are copying most left pixels instead of copying required rectangle.
Signed-off-by: Gris87 <Gris87@yandex.ru>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Tested-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.
But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.
This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in ShellPkg which don't have the policy to defer the
execution of the image.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.
But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.
This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the caller in PlatformDriOverrideDxe which don't have the policy to
defer the execution of the image.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.
But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.
This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in UefiBootManagerLib which don't have the policy to defer
the execution of the image.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.
But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.
This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in DxeCapsuleLibFmp which don't have the policy to defer
the execution of the image.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
For the LoadImage() boot service, with EFI_SECURITY_VIOLATION retval,
the Image was loaded and an ImageHandle was created with a valid
EFI_LOADED_IMAGE_PROTOCOL, but the image can not be started right now.
This follows UEFI Spec.
But if the caller of LoadImage() doesn't have the option to defer
the execution of an image, we can not treat EFI_SECURITY_VIOLATION
like any other LoadImage() error, we should unload image for the
EFI_SECURITY_VIOLATION to avoid resource leak.
This patch is to do error handling for EFI_SECURITY_VIOLATION explicitly
for the callers in EmbeddedPkg which don't have the policy to defer the
execution of the image.
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Philippe Mathieu-Daude <philmd@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2182
Inorder to support VS2019, we add VS2019 config process
in Setup Batch Files,
Because VS2019 and VS2017 could using same vswhere.exe
to detect the InstallationPath,
So we add the -version as the parameter of vswhere
to get the correct VS2017/VS2019's InstallationPath
v3: In BaseTools\set_vsprefix_envs.bat,
move WINSDK10_PREFIX setting into VCToolsInstallDir check condition.
Cc: Amy Chan <amy.chan@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Ching JenX Cheng <ching.jenx.cheng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Pete Batard <pete@akeo.ie>
This reverts commit bc9e4194cf.
This change causes the dependent header files are missing in Makefile.
It makes the incremental build not work. So, revert this change.
Cc: Bob Feng<bob.c.feng@Intel.com>
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng<bob.c.feng@Intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2150
v4:
The v3 posting didn't do what it promised to do, so do it now for real.
V3 changes:
change to mov instruction (non locking instuction) instead
of xchg to simplify design.
V2 changes:
Add xchg 16 bit instructions to handle sgdt and sidt base
63:48 bits and 47:32 bits.
Add comment to explain why xchg 64bit isnt being used
Split lock happens when a locking instruction is used on mis-aligned data
that crosses two cachelines. If close source platform enables Alignment
Check Exception(#AC), They can hit a double fault due to split lock being
in CpuExceptionHandlerLib.
sigt and sgdt saves 10 bytes to memory, 8 bytes is base and 2 bytes is limit.
The data is mis-aligned, can cross two cacheline, and a xchg
instruction(locking instuction) is being utilize.
Signed-off-by: John E Lofgren <john.e.lofgren@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Due to needs a tackling the deficiency of the AP API, it's necessary to
ensure that in non-blocking mode previous AP executed command is
finished before starting new one.
To remedy above:
1) execute AcquireSpinLock instead AcquireSpinLockOrFail - this will
ensure time "window" to eliminate potential race condition between
BSP and AP spinLock release in non-blocking mode.
This also will eliminate possibility to start executing new AP
function before last is finished.
2) remove returns EFI_STATUS - EFI_NOT_READY - in new scenario returned
status is not necessary to caller.
Signed-off-by: Damian Nikodem <damian.nikodem@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Benjamin You <benjamin.you@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Krzysztof Rusocki <krzysztof.rusocki@intel.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2201
An error occurs using special VpdPcd that is not used in the Inf file
In dsc:
[PcdsDynamicExVpd.common.DEFAULT]
gBoardModuleTokenSpaceGuid.test1|*|{CODE({
{0x0} // terminator
})}
In dec:
[PcdsDynamicEx]
# Vpd GPIO table
gBoardModuleTokenSpaceGuid.test1|{0}|GPIO_INIT_CONFIG[]|0x50000018 {
<HeaderFiles>
Library/GpioLib.h
<Packages>
MdePkg/MdePkg.dec
}
ValueError: invalid literal for int() with base 0: '*'
This Patch is going to fix issue
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The StandaloneMmPkg .DSC file went out of sync with the changes
applied to the package when I enabled this code on the Synquacer
platform in edk2-platforms. So apply the necessary changes to make
this package build in isolation.
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2188
build -p MdeModulePkg\MdeModulePkg.dsc -a IA32 -m
MdeModulePkg\Universal\PCD\Pei\Pcd.inf
Error:
AttributeError: 'PlatformInfo' object has no attribute
'DynamicPcdList'
The DSC data object used to build a separate module today
is PlatformInfo rather than PlatformAutoGen
'PlatformAutoGen' object has attribute 'DynamicPcdList'
This patch is going to fixed this issue
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The header files are used but missing in INF, which causes
warning message when building them.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
After upgrading the CI system we use for building the ArmVirtPkg
targets, we started seeing failures due to the NOOPT build running
out of space when using the CLANG38 toolchain definition combined
with clang 7.
We really don't want to increase the FD/FV sizes in general to
accommodate this, so parameterize the relevant quantities and
increase them by 50% for NOOPT builds.
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Today's behavior is to enable 5l paging when CPU supports it
(CPUID[7,0].ECX.BIT[16] is set).
The patch changes the behavior to enable 5l paging when two
conditions are both met:
1. CPU supports it;
2. The max physical address bits is bigger than 48.
Because 4-level paging can support to address physical address up to
2^48 - 1, there is no need to enable 5-level paging with max
physical address bits <= 48.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
When building BaseTools, GNUmakefile builds create directory
BaseTools/Source/C/libs/. On the other hand, Makefile builds use libs
as an nmake pseudo target, so it either must NOT exist as a file or
directory, OR it must phony dependency like .PHONY. The latter
solution conflicts with NmakeSubdirs.py. Therefore, I make it go away
in the cleanall target. I could also add it to the clean target, but
it strikes me that cleanall should be more forceful.
Signed-off-by: Burt Silverman <burtms@gmail.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2157
Hii Pcd links to a efi variable. The Variable
default value is evaluated by related Hii Pcds
setting. If multiple Hii Pcds links to one variable,
and the offset overlap, the later Hii Pcds setting
should be effective. There is a tool bug that is if
the Pcds are in different dsc file which are included
into the platform dsc file, build tool does not get
the Pcds relative position correctly. That means
build tool does not know which Pcd is the later one. As
the result, the variable default value will be incorrect.
This patch is to fix this bug.
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
To support auto-connection, EFI_BLUETOOTH_LE_SMP_DATA_TYPE needs to
add a new data type EfiBluetoothSmpPeerAddressList which associates
with a list of Bluetooth per address connected before.
This new data type was added in UEFI spec 2.7b.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1778
We are going to add keyword (lower case) 'static' for functions and global
variables which are not referenced outside their current C file.
However, the ECC tool only recognizes upper case 'STATIC' at this moment.
This will lead to issue reports for new codes that follow the above coding
style.
This patch is going to handle lower case 'static'
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The LoadImage() boot service is a bit unusual in that it allocates
resources in a particular failure case; namely, it produces a valid
"ImageHandle" when it returns EFI_SECURITY_VIOLATION. This is supposed to
happen e.g. when Secure Boot verification fails for the image, but the
platform policy for the particular image origin (such as "fixed media" or
"removable media") is DEFER_EXECUTE_ON_SECURITY_VIOLATION. The return code
allows platform logic to selectively override the verification failure,
and launch the image nonetheless.
ArmVirtPkg/PlatformBootManagerLib does not override EFI_SECURITY_VIOLATION
for the kernel image loaded from fw_cfg -- any LoadImage() error is
considered fatal. When we simply treat EFI_SECURITY_VIOLATION like any
other LoadImage() error, we leak the resources associated with
"KernelImageHandle". From a resource usage perspective,
EFI_SECURITY_VIOLATION must be considered "success", and rolled back.
Implement this rollback, without breaking the proper "nesting" of error
handling jumps and labels.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1992
Fixes: 23d04b58e2
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Incorporate the stack protector library into the AARCH64 build of
the Shell binaries as a NULL library resolution, to avoid build
errors when the compiler injects stack integrity checks.
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
In some cases, the CLANG38 toolchain profile in LTO mode emits GOT
based relocations in spite of our attempts to avoid this, by using
hidden visibility, -Bsymbolic etc.
On AARCH64, we managed to work around this by processing the GOT
based relocations in GenFw. As it turns out, the same issue exists
on 32-bit ARM, but unfortunately, we cannot use a similar trick to
get rid of the GOT entry, and the relocation metadata is insufficient
to locate the GOT entry in the binary.
Note that in this particular case, we are interested in PIE linking
only (i.e., producing a .rela section containing dynamic relocations
that the startup code can process directly), and not in position
independent code generation, and by passing the -pie option to the
linker directly using -Wl,-pie (and dropping -shared), we can coerce
the GOLD linker into doing only the former rather than both when it
performs its LTO code generation.
Acked-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2153
Current logic will skip searching EFI_PEI_CORE_FV_LOCATION_PPI when the
PPI in PpiList having EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST flag,
but platform may pass single PPI in PpiList that should be supported.
Changed the logic to verify PpiList first before checking
EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST flag.
Test: Verified both single EFI_PEI_CORE_FV_LOCATION_PPI and multiple
PPIs in PpiList cases and both can boot with the PeiCore
specified by EFI_PEI_CORE_FV_LOCATION_PPI.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
We take great care to avoid GOT based relocations in EDK2 executables,
primarily because they are pointless - we don't care about things like
the CoW footprint or relocations that target read-only sections, and so
GOT entries only bloat the binary.
However, in some cases (e.g., when building the relocatable PrePi SEC
module in ArmVirtPkg with the CLANG38 toolchain), we may end up with
some GOT based relocations nonetheless, which break the build since
GenFw does not know how to deal with them.
The relocations emitted in this case are ADRP/LDR instruction pairs
that are annotated as GOT based, which means that it is the linker's
job to emit the GOT entry and tag it with an appropriate dynamic
relocation that ensures that the correct absolute value is stored into
the GOT entry when the executable is loaded. This dynamic relocation is
not visible to GenFw, and so populating the PE/COFF relocation section
for these entries is non-trivial.
Since each ADRP/LDR pair refers to a single symbol that is local to the
binary (given that shared libraries are not supported), we can actually
convert the ADRP/LDR pair into an ADRP/ADD pair that produces the symbol
address directly rather than loading it from memory. This leaves the
GOT entry in the binary, but since it is now unused, it is no longer
necessary to emit a PE/COFF relocation entry for it.
Acked-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1955
Refer to PCI express base specification Reversion 5.0, Version
1.0, Table 7-33, Supported Link Speeds Vector bit 3 indicate
the speed 16 GT/s and bit 4 indicate the speed 32 GT/s.
Add the support to shell command 'pci ...'.
Change the MaxLinkSpeed other values' result from 'Unknown'
to 'Reserved' to make the result align.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Oleksiy <oleksiyy@ami.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
PcdRealTimeClockUpdateTimeout is now defined in MdeModulePkg.dec.
This is the only reason that causes PcAtChipsetPkg depends on
MdeModulePkg.
Move the PCD from MdeModulePkg.dec to PcAtChipsetPkg.dec removes
such dependency.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
There are three PCDs that may impact the behavior of each other in
SMM environment:
PcdCpuSmmProfileEnable
PcdHeapGuardPropertyMask in MdeModulePkg
PcdCpuSmmRestrictedMemoryAccess
The patch updates the comments in DEC file to document it.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Today's behavior is to always restrict access to non-SMRAM regardless
the value of PcdCpuSmmRestrictedMemoryAccess.
Because RAS components require to access all non-SMRAM memory, the
patch changes the code logic to honor PcdCpuSmmRestrictedMemoryAccess
so that only when the PCD is true, the restriction takes affect and
page table memory is also protected.
Because IA32 build doesn't reference this PCD, such restriction
always takes affect in IA32 build.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The patch changes PiSmmCpu driver to consume PCD
PcdCpuSmmRestrictedMemoryAccess.
Because the behavior controlled by PcdCpuSmmStaticPageTable in
original code is not changed after switching to
PcdCpuSmmRestrictedMemoryAccess.
The functionality is not impacted by this patch.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The patch adds a new X64 only PCD PcdCpuSmmRestrictedMemoryAccess.
The PCD indicates access to non-SMRAM memory is restricted to
reserved, runtime and ACPI NVS type after SmmReadyToLock.
MMIO access is always allowed regardless of the value of this PCD.
Loose of such restriction is only required by RAS components in X64
platforms.
The PCD value is considered as constantly TRUE in IA32 platforms.
When the PCD value is TRUE, page table is initialized to cover all
memory spaces and the memory occupied by page table is protected by
page table itself as read-only.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Since TianoCore EDK2 commit d65f2cea36 ("ShellPkg/CommandLib: Locate
proper UnicodeCollation instance") in edk2 the UEFI Shell crashes if EFI
variable PlatformLang is not defined due to dereferencing gUnicodeCollation
gUnicodeCollation (= NULL) in ShellCommandRegisterCommandName().
Furthermore CommandInit() is leaking PlatformLang if
gUnicodeCollation != NULL.
Close the memory leak and use the first UnicodeCollation instance if
PlatfomLang is not defined.
Fixes: d65f2cea36 ("ShellPkg/CommandLib: Locate proper UnicodeCollation
instance")
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2138
Added checks for return parameters of GetSupportedTypes
function calls in InternalHstiFindAip to improve error handling.
An issue was observed on Dell Poweredge R740, where the Dell
PERC H740P controller UEFI driver returned InfoTypesBuffer = NULL,
InfoTypesBufferCount = 0 and caused an FreePool assert.
Signed-off-by: Jayanth Raghuram <Jayanth.Raghuram@Dell.com>
Cc: Wei G Liu <Wei_G_Liu@Dell.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2136
SecPlatformMain is a platform hook function which let platform does
some update. Some platform may adjust SecCoreData->PeiTemporaryRamBase
which caused former saved AllSecPpiList variable invalid.
This patch update the logic to get AllSecPpiList after SecPlatformMain.
If SecPlatformMain() returns no platform-specific PPI list, then there
is nothing to merge, so we don't need "AllSecPpiList" at all.
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2104
When UEFI Applications or UEFI Drivers are unloaded,
the PeCoffLoaderUnloadImageExtraAction() needs to unload
the image using FreeLibrary() if the image was successfully
loaded using LoadLibrrayEx().
This is a regression from the Nt32Pkg that supported
unloading applications and drivers as well as loading
the same application or driver multiple times.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Andrew Fish <afish@apple.com>
Tested-by: Tim Lewis <tim.lewis@insyde.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2103
Current CopyFileOnChange() and SaveFileOnChange() in
BaseTools\Source\Python\Common\Misc.py don't use the dedicated
long file path API to handle the file path strings and cannot
support the long file path copy and save in windows. This patch
enhances them to support the long file path copy and save
correctly.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Steven Shi <steven.shi@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Introduce PcdXenGrantFrames to replace a define in XenBusDxe and allow
the same value to be used in a different module.
The reason for the number of page to be 4 doesn't exist anymore, so
simply remove the comment.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-33-anthony.perard@citrix.com>
On a Xen PVH guest, none of the existing serial or console interface
works, so we add a new one, based on XenConsoleSerialPortLib, and
implemented via SerialDxe.
That is a simple console implementation that can work on both PVH
guest and HVM guests, even if it is rarely going to be used on HVM.
Have PlatformBootManagerLib look for the new console, when running as a
Xen guest.
Since we use VENDOR_UART_DEVICE_PATH, fix its description and coding
style.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-32-anthony.perard@citrix.com>
When running as a Xen PVH guest, there is no CMOS to read the memory
size from. Rework GetSystemMemorySize(Below|Above)4gb() so they can
work without CMOS by reading the e820 table.
Rework XenPublishRamRegions to also care for the reserved and ACPI
entry in the e820 table. The region that was added by InitializeXen()
isn't needed as that same entry is in the e820 table provided by
hvmloader.
MTRR settings aren't modified anymore, on HVM it's already done by
hvmloader, on PVH it is supposed to have sane default. MTRR will need
to be done properly but keeping what's already been done by programs
that have run before OVMF will do for now.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-24-anthony.perard@citrix.com>
The ACPI Timer isn't present in a PVH guest, but local APIC works on
both PVH and HVM.
Note that the use of SecPeiDxeTimerLibCpu might be an issue with a
driver of type DXE_RUNTIME_DRIVER. I've attempted to find out which of
the DXE_RUNTIME_DRIVER uses the TimerLib at runtime. I've done that by
replacing the TimerLib evaluation in
[LibraryClasses.common.DXE_RUNTIME_DRIVER] by a different one and
checking every module that uses it (with the --report-file=report
build option).
ResetSystemRuntimeDxe is calling the TimerLib API at runtime to do the
operation "EfiResetCold", so this may never complete if the OS have
disabled the Local APIC Timer.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-10-anthony.perard@citrix.com>
This patch allows the ResetVector to be run indenpendently from build
time addresses.
The goal of the patch is to avoid having to create RAM just below 4G
when creating a Xen PVH guest while being compatible with the way
hvmloader currently load OVMF, just below 4G.
Only the new PVH entry point will do the calculation.
The ResetVector will figure out its current running address by creating
a temporary stack, make a call and calculate the difference between the
build time address and the address at run time.
This patch copies and make the necessary modification to some other asm
files:
- copy of UefiCpuPkg/.../Flat32ToFlat64.asm:
Allow Transition32FlatTo64Flat to be run from anywhere in memory
- copy of UefiCpuPkg/../SearchForBfvBase.asm:
Add a extra parameter to indicate where to start the search for the
boot firmware volume.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-9-anthony.perard@citrix.com>
This patch changes the flash device image of OvmfXen to make it look
like it's an ELF. For this, we replace the empty embedded variable store
by a binary array, which is a ELF file header.
The ELF header explain to a loader to load the binary at the address
1MB, then jump to the PVH entry point which will be created in a later
patch. The header also includes a Xen ELF note that is part of the
PVH ABI.
That patch include OvmfXenElfHeaderGenerator.c which can be use to
regenerate the ELF header, but this will be a manual step.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-6-anthony.perard@citrix.com>
Introduce XenPlatformPei, a copy of OvmfPkg/PlatformPei without some
of QEMU specific initialization, Xen does not support QemuFwCfg.
This new module will be adjusted to accommodate Xen PVH.
fw_cfg dependents that have been removed, which are dynamically skipped
when running PlatformPei on Xen:
- GetFirstNonAddress(): controlling the 64-bit PCI MMIO aperture via the
(experimental) "opt/ovmf/X-PciMmio64Mb" file
- GetFirstNonAddress(): honoring the hotplug DIMM area
("etc/reserved-memory-end") in the placement of the 64-bit PCI MMIO
aperture
- NoexecDxeInitialization() is removed, so PcdPropertiesTableEnable and
PcdSetNxForStack are left constant FALSE (not set dynamically from
fw_cfg "opt/ovmf/PcdXxxx")
- MaxCpuCountInitialization(), PublishPeiMemory(): the max CPU count is
not taken from the QemuFwCfgItemSmpCpuCount fw_cfg key;
PcdCpuMaxLogicalProcessorNumber is used intact and
PcdCpuApInitTimeOutInMicroSeconds is never changed or used.
- InitializeXenPlatform(), S3Verification(): S3 is assumed disabled (not
consulting "etc/system-states" via QemuFwCfgS3Enabled()).
- InstallFeatureControlCallback(): the feature control MSR is not set
from "etc/msr_feature_control"
(also removed FeatureControl.c as there is nothing been executed)
Also removed:
- SMRAM/TSEG-related low mem size adjusting (PcdSmmSmramRequire is
assumed FALSE) in PublishPeiMemory(),
- QemuInitializeRam() entirely,
Xen related changes:
- Have removed the module variable mXen, as it should be always true.
- Have the platform PEI initialization fails if Xen has not been
detected.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-5-anthony.perard@citrix.com>
Introduce XenResetVector, a copy of OvmfPkg/ResetVector, with one
changes:
- SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0)
Xen copies the OVMF code to RAM, there is no need to disable cache.
This new module will later be modified to add a new entry point, more
detail in a following commit "OvmfPkg/XenResetVector: Add new entry point
for Xen PVH"
Value FILE_GUID of XenResetVector have not changed compare to ResetVector
because it is a special value (gEfiFirmwareVolumeTopFileGuid).
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-4-anthony.perard@citrix.com>
OvmfXen is a copy of OvmfX64, removing VirtIO and some SMM.
This new platform will be changed to make it works on two types of Xen
guest: HVM and PVH.
Compare to OvmfX64, this patch:
- changed: PLATFORM_GUID, OUTPUT_DIRECTORY, FLASH_DEFINITION
- removed: VirtioLib class resolution
- removed: all UEFI_DRIVER modules for virtio devices
- removed: DXE_SMM_DRIVER and SMM_CORE lib class resolutions
- removed: DXE_SMM_DRIVER and SMM_CORE FDF rules
- removed: Everything related to SMM_REQUIRE==true
- removed: Everything related to SECURE_BOOT_ENABLE==true
- removed: Everything related to TPM2_ENABLE==true
- changed: PcdPciDisableBusEnumeration dynamic default flipped to TRUE
- changed: default FD_SIZE_IN_KB to 2M.
- reverted d272449d9e, "OvmfPkg: raise DXEFV size to 11 MB"
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-3-anthony.perard@citrix.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2040
Below code is current implementation:
if (MsrRegister[ProcessorNumber].Bits.Lock == 0) {
CPU_REGISTER_TABLE_WRITE_FIELD (
ProcessorNumber,
Msr,
MSR_IA32_FEATURE_CONTROL,
MSR_IA32_FEATURE_CONTROL_REGISTER,
Bits.Lock,
1
);
}
1. In first normal boot, the Bits.Lock is 0, 1 will be added
into the register table and then will set to the MSR.
2. Trig warm reboot, MSR value preserves. After normal boot phase,
the Bits.Lock is 1, so it will not be added into the register
table during the warm reboot phase.
3. Trig S3 then resume, the Bits.Lock change to 0 and Bits.Lock is
not added in register table, so it's still 0 after resume. This
is not an expect behavior. The expect value is the value should
always 1 after booting or resuming from S3.
The root cause for this issue is
1. driver bases on current value to insert the "set value action" to
the register table.
2. Some MSRs may reserve their value during warm reboot.
The solution for this issue is using new added macros for the MSRs which
preserve value during warm reboot.
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2040
Add below new micros which test the current value before write the new
value. Only write new value when current value not same as new value.
CPU_REGISTER_TABLE_TEST_THEN_WRITE32
CPU_REGISTER_TABLE_TEST_THEN_WRITE64
CPU_REGISTER_TABLE_TEST_THEN_WRITE_FIELD
Also add below API:
CpuRegisterTableTestThenWrite
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Cc: Star Zeng <star.zeng@intel.com>
Reclaim may free page table pages that are required to handle current page
fault. This causes a page leak, and, after sufficent number of specific
page fault+reclaim pairs, we run out of reclaimable pages and hit:
ASSERT (MinAcc != (UINT64)-1);
To remedy, prevent pages essential to handling current page fault:
(1) from being considered as reclaim candidates (first reclaim phase)
(2) from being freed as part of "branch cleanup" (second reclaim phase)
Signed-off-by: Damian Nikodem <damian.nikodem@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Krzysztof Rusocki <krzysztof.rusocki@intel.com>
The Fpdt driver (FirmwarePerformanceDxe) saves a memory address across
reboots, and then does an AllocatePage for that memory address.
If, on this boot, that memory comes from a Runtime memory bucket,
the MAT table is not updated. This causes Windows to boot into Recovery.
This patch blocks the memory manager from changing the page
from a special bucket to a different memory type. Once the buckets are
allocated, we freeze the memory ranges for the OS, and fragmenting
the special buckets will cause errors resuming from hibernate (S4).
The references to S4 here are the use case that fails. This
failure is root caused to an inconsistent behavior of the
core memory services themselves when type AllocateAddress is used.
The main issue is apparently with the UEFI memory map -- the UEFI memory
map reflects the pre-allocated bins, but the actual allocations at fixed
addresses may go out of sync with that. Everything else, such as:
- EFI_MEMORY_ATTRIBUTES_TABLE (page protections) being out of sync,
- S4 failing
are just symptoms / consequences.
This patch is cherry pick from Project Mu:
a9be767d9b
With the minor change,
1. Update commit message format to keep the message in 80 characters one line.
2. Remove // MU_CHANGE comments in source code.
3. Update comments style to follow edk2 style.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Liming Gao <liming.gao@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=2079
The Basetool CopyFileOnChange() and SaveFileOnChange()
functions might raise the IOError occasionally when build
in Windows with multi-process and build cache enabled.
The CopyFileOnChange() and SaveFileOnChange() might be invoked
in multiple sub-processes simultaneously, and this patch adds
global locks to sync these functions invoking which can
harden their reliability.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Steven Shi <steven.shi@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1951
Current build cache use the module's [self.Arch][self.Name]
info as the ModuleAutoGen object key in hash list and dictionary.
The [self.Arch][self.Name] is not safe as the module key because
there could be two modules with same module name and arch name in
one platform. E.g. A platform can override a module or library
instance in another different path, the overriding module can has
the same module name and arch name as the original one.
Directly use the ModuleAutoGen obj self as the key, because
the obj __hash__ and __repr__ attributes already contain the
full path and arch name.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Steven Shi <steven.shi@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1927
Current cache hash algorithm does not parse and generate
the makefile to get the accurate dependency files for a
module. It instead use the platform and package meta files
to get the module depenedency in a quick but over approximate
way. These meta files are monolithic and involve many redundant
dependency for the module, which cause the module build
cache miss easily.
This patch introduces one more cache checkpoint and a new
hash algorithm besides the current quick one. The new hash
algorithm leverages the module makefile to achieve more
accurate and precise dependency info for a module. When
the build cache miss with the first quick hash, the
Basetool will caculate new one after makefile is generated
and then check again.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Steven Shi <steven.shi@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1941
The two CHAR16 array ChildCountStr and DeviceCountStr is
defined to hold the decimal string data of UINTN. The max
of UINTN is 18446744073709551615 and it contain 20 characters.
So make their size to 21 CHAR16s to hold the string data with
a null-terminate.
UnicodeValueToStringS regard the value input as INT64, and
21 CHARs is enough to hold the lowest value with minus '-'.
Although the value shouldn't be such big.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Oleksiy <oleksiyy@ami.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Linson Augustine <Linson.augustine@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
The local variable PpiArray[10] is declared in the middle
of the SEC module _ModuleEntryPoint() with its own scope.
However, PpiArray has a dangling reference to its location
on the stack after the scope is closed. This causes issues
with some compilers (e.g. XCODE5).
The fix is to move the declaration of PpiArray[10] to
the beginning of the function, so it is scoped correctly
for all references to this local variable and references
to its location.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Andrew Fish <afish@apple.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Andrew Fish <afish@apple.com>
Disable TftpDynamicCommand for XCODE5 because this command
places HII content in an PE/COFF resource section that is not
supported by the XCODE5 tool chain, and the missing HII
content causes the load of this command to ASSERT().
Disable the LogoDxe module that places the logo bitmap in
a PE/COFF resource section that is not supported by the
XCODE5 tool chain, and the missing HII content causes
the load of this module to ASSERT().
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Andrew Fish <afish@apple.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Andrew Fish <afish@apple.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2056
The IA32 build of the EmulatorPkg for VS20xx does not boot
because the default value of PCD PcdPeiServicesTablePage
rarely succeeds to be mapped on IA32 Windows Host Environments.
Change the DEC default value for this PCD to a value that
is compatible with Windows and POSIX host environments for
IA32 and X64. For IA32 builds, this 64-bit PCD is truncated
to a 32-bit value.
PcdPeiServicesTablePage is changed from 0x1003000000 to
0x1013000000. With this new value, no boot failures are
observed. However, the use of this hard coded value can
potentially cause a boot failure if this address specified
by the PCD is already allocated in the user process.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Tested-by: Andrew Fish <afish@apple.com>
Initialize PageMapLevel5Entry at the beginning of the function.
This commit will fix a GCC 4.8.5 build failure introduced by commit
b3527dedc3.
OvmfPkg build failure wtih gcc 4.8.5 still exists at latest edk2 version.
The commit 46f8a68916 seems not to fix
the build failure completely.
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1837
The tool is designed to generate Windows Firmware Update Drivers,
the input is one drivername.cap with related parameters, the output
Windows Driver package are composed by drivername.cap, drivername.inf
and drivername.cat to update the single payload in device.
usage:
GenerateWindowsDriver [-h] [--output-folder OUTPUTFOLDER]
[--product-fmp-guid PRODUCTFMPGUID]
[--capsuleversion-dotstring CAPSULEVERSION_DOTSTRING]
[--capsuleversion-hexstring CAPSULEVERSION_HEXSTRING]
[--product-fw-provider PRODUCTFWPROVIDER]
[--product-fw-mfg-name PRODUCTFWMFGNAME]
[--product-fw-desc PRODUCTFWDESC]
[--capsule-file-name CAPSULEFILENAME]
[--pfx-file PFXFILE] [--arch ARCH]
[--operating-system-string OPERATINGSYSTEMSTRING]
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Kinney Michael D <michael.d.kinney@intel.com>
Signed-off-by: Eric Jin <eric.jin@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1525
Add PCD PcdFmpDeviceStorageAccessEnable. If this PCD is
TRUE, then the Firmware Management Protocol supports access
to the firmware storage device. This is the default setting.
If FALSE, then Firmware Management Protocol services that
access the firmware storage device return EFI_UNSUPPORTED
except GetImageInfo(). Setting this value to FALSE produces
the smallest possible FmpDxe driver that still advertises the
updatable firmware component in the ESRT.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Eric Jin <eric.jin@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1525
* Add Capsule Update Policy Protocol to FmpDevicePkg
* Add CapsuleUpdatePolicyLib instance that uses the services
of the Capsule Update Policy Protocol
* Add module that produces the Capsule Update Policy
Protocol using the services of the CapsuleUpdatePolicyLib
class.
* Update FmpDevicePkg DSC to build the new library instance
and the new module and update builds of FmpDxe modules
to demonstrate the use of the different CapsuleUpdatePolicyLib
instances.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Wang Fan <fan.wang@intel.com>
Reviewed-by: Eric Jin <eric.jin@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
buildoptions is used by build.py and TargetTxtClassObj.py
Move buildoptions.py to Common folder so that
build tool and ECC tool work fine.
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
This commit will fix a GCC 4.8.5 build failure introduced by commit
b3527dedc3.
PageMapLevel5Entry may be uninitialized in original code, which means
uninitialized pointer will be modified at some circumstance.
So relocate the operation of PageMapLevel5Entry++ in order to make sure
the pointer could be modified only when it is initialized.
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
This commit adds EDKII_UFS_HC_PLATFORM_PROTOCOL implementation
in UfsPassThruDxe driver in version 1. Driver assumes that at
most one instance of the protocol exists in the system. Presence
of the protocol is not mandatory.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
Private data has been refactored to use EDKII_UFS_HC_INFO structure
to store host controller capabilities and version
information. Getting host controller data has been moved
into single place and is done before host controller enable.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1343
EDKII_UFS_HC_PLATFORM_PROTOCOL will allow the platform to inject
platform specific logic into standard UFS flows. Right now we
support callbacks pre and post host controller enable and pre
and post link startup. Provided callbacks allow the platform
driver to inject UIC programming after HCE is set which is
a standard initialization step covered by UFS specification as
well as cover some additional use cases during other callbacks.
For instance platform driver may switch to fast mode after link
startup.
We also allow the platform to override host controller capabilities
and version which might be useful to manage silicon bugs or
allow testing experimental features from new versions of the
specification.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2049
ShellPkg\Library\UefiShellLevel2CommandsLib\Cp.c line 104 and
ShellPkg\Library\UefiShellLevel2CommandsLib\Mv.c line 640, the
pointer variable Response may be a NULL pointer. So we should
make sure that it isn't NULL before dereference it.
If Response is NULL that indicates a EFI_OUT_OF_RESOURCES
error, directly return SHELL_ABORTED.
Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Modify the SRAT parsing logic to prevent reading past the table buffer
length provided.
Check if the Static Resource Allocation Structure's buffer fits in the
SRAT table buffer before its contents are dumped.
Prevent buffer overruns when reading the Static Resource Allocation
Structure's header.
References:
- ACPI 6.3, January 2019, Section 5.2.16
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@inte.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Modify the PPTT table parsing logic to prevent reading past the ACPI
buffer lengths provided.
Check if the Number of Private Resources specified in the Processor
Hierarchy Node (Type 0) is possible given the Type 0 Structure's buffer
length.
Make sure that the processor topology structure's buffer fits in the
PPTT table buffer before its contents are dumped.
Prevent buffer overruns when reading the processor topology structure's
header.
References:
- ACPI 6.3, January 2019, Section 5.2.29
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@inte.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Modify the parsing logic to prevent reading past the MADT table buffer
length provided when parsing the Interrupt Controller Structure header.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@inte.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Modify the IORT table parsing logic to prevent reading past the buffer
lengths provided.
Change DumpIortNodeIdMappings() function's signature and implementation
to simplify buffer overrun prevention. Update all calls to this
function accordingly.
Modify the parser for each type of IORT node such that the offset from
the start of the node's buffer is tracked as the parsing function is
executed. Again, this change helps prevent buffer overruns.
Test that the IORT node buffer fits in the table buffer before the
node's buffer contents are dumped.
References:
- IO Remapping Table (Issue D), Platform Design Document, March 2018
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@inte.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Modify the GTDT table parsing logic to prevent reading past the ACPI
buffer lengths provided and to make it consistent with other table
parsers. This includes converting the do-while loop in ParseAcpiGtdt()
into a while loop.
Remove a check which ensures that the entire Platform GT Block
Structure buffer has been parsed. The ACPI specification does not ban
from defining buffers which are larger than the size indicated by the
count and sizes of substructures which constitute it.
Change the data type of the Length parameter to the DumpGTBlock()
function to reflect the width of the respective ACPI structure's
field.
References:
- ACPI 6.3, January 2019, Table 5-124
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@inte.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Modify the DBG2 table parsing logic to prevent reading past the ACPI
buffer lengths provided.
Modify the signature of the DumpDbgDeviceInfo() function to make it
consistent with the ACPI structure processing functions in other
acpiview parsers. Now, the length of the Debug Device Information
Structure is read before the entire structure is dumped.
This refactoring change makes it easier to stop reading beyond the
DBG2 table buffer if the Debug Device Information Structure Buffer
does not fit in the DBG2 buffer.
For processing the first two fields of the Debug Device Information
Structure (to get the length) a new ACPI_PARSER array is defined.
References:
- Microsoft Debug Port Table 2 (DBG2), December 10, 2015
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@inte.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2051
Original code GetConfigTable for AddrPtr first, if failed,
InstalConfigTable with allocated AddrPtr. So the AddrPtr
should not be NULL and the NULL pointer dereference case
should be false positive. This patch is just to address
the case raised from static analysis.
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1875
1. Separate the AutoGen.py into 3 small py files.
One is for AutoGen base class, one is for WorkspaceAutoGen class
and PlatformAutoGen class, and the one for ModuleAutoGen class.
2. Create a new class DataPipe to store the Platform scope settings.
Create a new class PlatformInfo to provide the same interface
as PlatformAutoGen. PlatformInfo class is initialized by
DataPipe instance.
Create a new class WorkspaceInfo to provide the same interface
as WorkspaceAutoGen. WorkspaceInfo class is initialized by
DataPipe instance.
3. Change ModuleAutoGen to depends on DataPipe, PlatformInfo and
WorkspaceInfo. Remove the dependency of ModuleAutoGen to PlatformAutoGen.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1928
1. Implement OpenSSL HKDF wrapped function in CryptHkdf.c file.
2. Implement stub implementation function in CryptHkdfNull.c file.
3. Add wrapped HKDF function declaration to BaseCryptLib.h file.
4. Add CryptHkdf.c to module information BaseCryptLib.inf file.
5. Add CryptHkdfNull.c to module information PeiCryptLib.inf,
RuntimeCryptLib.inf and SmmCryptLib.inf
Signed-off-by: Gary West <Gary.West@intel.com>
Cc: Jian Wang <jian.j.wang@intel.com>
Cc: Ting Ye <ting.ye@intel.com>
Reviewed-by: Jian Wang <jian.j.wang@intel.com>
The patch moves all files under UefiCpuPkg/Include/Register/ to
MdePkg/Include/Register using following detailed approaches:
1. Move UefiCpuPkg/Include/Register/Amd/ to
MdePkg/Include/Register/Amd folder.
2. Move remaining in UefiCpuPkg/Include/Register/ to
MdePkg/Include/Register/Intel folder.
3. Create wrapper header files under UefiCpuPkg/Include/Register/
to include the accordingly files in MdePkg/Include/Register/Intel.
This is to avoid build break because code in other repos like
edk2-platform includes the file from UefiCpuPkg.
The wrapper header files will be removed after all consumers code
is updated.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Signed-off-by: Eric Dong <eric.dong@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2008
DxeIpl is responsible to create page table for DXE phase running
either in long mode or in 32bit mode with certain protection
mechanism enabled (refer to ToBuildPageTable()).
The patch updates DxeIpl to create 5-level page table for DXE phase
running in long mode when PcdUse5LevelPageTable is TRUE and CPU
supports 5-level page table.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Eric Dong <eric.dong@intel.com>
Today's code defines macros like CR0_PG, CR0_WP, CR4_PSE, CR4_PAE
when checking whether individual bits are set in CR0 or CR4 register.
The patch changes the code to use IA32_CR0 and IA32_CR4 structure
defined in MdePkg/Include/Library/BaseLib.h so that the module
local macros can be removed.
There is no functionality impact to this change.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Eric Dong <eric.dong@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2008
MpInitLib is the library that's responsible to wake up APs to provide
MP PPI and Protocol services.
The patch synchronizes BSP's CR4.LA57 to each AP's CR4.LA57.
Without this change, AP may enter to GP fault when BSP's 5-level page
table is set to AP during AP wakes up.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Eric Dong <eric.dong@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1525
The patch is to merge multiple FMP instances into single ESRT entry
when they have the same GUID.
The policy to LastAttemptStatus/LastAttemptVersion of ESRT entry is:
If all the LastAttemptStatus are LAST_ATTEMPT_STATUS_SUCCESS, then
LastAttemptVersion should be the smallest of LastAttemptVersion. If
any of the LastAttemptStatus is not LAST_ATTEMPT_STATUS_SUCCESS,
then the LastAttemptVersion/LastAttemptStatus should be the values
of the first FMP instance whose LastAttemptStatus is not
LAST_ATTEMPT_STATUS_SUCCESS.
To detect possible duplicated GUID/HardwareInstance, a table of
GUID/HardwareInstance pairs from all the EFI_FIRMWARE_IMAGE_DESCRIPTORs
from all FMP instances is built. If a duplicate is found, then generate
a DEBUG_ERROR message, generate an ASSERT(), and ignore the duplicate
EFI_FIRMWARE_IMAGE_DESCRIPTOR.
Add an internal worker function called FmpGetFirmwareImageDescriptor()
that retrieves the list of EFI_FIRMWARE_IMAGE_DESCRIPTORs from a single
FMP instance and returns the descriptors in an allocated buffer. This
function is used to get the descriptors used to build the table of
unique GUID/HardwareInstance pairs. It is then used again to generate
the ESRT Table from all the EFI_FIRMWARE_IMAGE_DESCRIPTORs from all the
FMP instances. 2 passes are performed so the total number of
descriptors is known. This allows the correct sized buffers to always
be allocated.
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Eric Jin <eric.jin@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2046
Make sure all libs that should be dynamically linked
are dynamically linked when XCODE5 compiler is used.
A previous change introduced the following pragma:
#pragma GCC visibility push (hidden)
When the EmulatorPkg is built using XCODE5 toolchain
for X64, this pragma is included and it generates a
linker error when building the Unix Host module. This
change uses !defined(__APPLE__) to prevent the use of
this pragma when building EmulatorPkg/Unix/Host.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2046
* Clean up XCODE5 IA32 [BuildOptions] and fix IA32
X11 include path.
* Add -DEFIAPI=__attribute__((ms_abi)) to X64 XCODE5
[BuildOptions]
* Use -target x86_64-apple-darwin for X64 XCODE5
[BuildOptions]
* Add Wl,-no_pie to X64 XCODE5 [BuildOptions]
* Address function type mismatch reported by XCODE5
in reverse gasket callback between UEFI ABI and
MacOS ABI. Use a UINTN to pass function address
to assembly code.
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
This debug message may be called by BSP and APs. It may
caused ASSERT when APs call this debug code.
In order to avoid system boot assert, Remove this debug
message.
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
This debug message may be called by BSP and APs. It may
caused ASSERT when APs call this debug code.
In order to avoid system boot assert, Remove this debug
message.
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
1.Remove "out" attribute for " Buffer" parameter in function header.
2.Add "out" attribute for " Token" parameter in function header.
3.Update ProcedureArgument to ProcedureArguments.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
For all other bcfg commands the "#" (option number) argument(s) are
treated as hexedecimal values regardless of whether or not they are
prefixed by "0x". This change fixes '-opt' to handle its "#"
(option number) argument consistently with the other commands.
Making this change removes a potential footgun whereby a user that
has been using a number without a "0x" prefix with other bcfg
commands finds that, on using that exact same number with '-opt', it
has this time unexpectedly been interpreted as a decimal number and
they have modified (corrupted) an unrelated load option. For
example, a user may have been specifying "10" to other commands to
have them act on the 16th option (because simply "10", without any
prefix, is how 'bcfg boot dump' displayed the option number for the
16th option). Unfortunately for them, if they also use '-opt' with
"10" it would unexpectedly and inconsistently act on the 10th option.
CC: Jaben Carsey <jaben.carsey@intel.com>
CC: Ray Ni <ray.ni@intel.com>
Signed-off-by: Jonathan Watt <jwatt@jwatt.org>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Bi Dandan <dandan.bi@intel.com>
Until now, during the USB device enumeration when its PortState
USB_PORT_STAT_CONNECTION bit was not set, the stack was not informed
that the device is not present. Fix that by returning appropriate
error code.
Signed-off-by: Marcin Wojtas <mw@semihalf.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1982
MpInitLibInitialize in MpLib.c will be invoked on both PEI and DXE
CPU code, MicrocodeDetect would be performed twice and copy
Microcode from flash to memory twice as well, which consider as
duplicate work to lead longer boot time.
This patch just use microcode memory copied in PEI phase if exist.
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Move Performance Monitoring Counter Group (PMCG) node ID mapping count
validation from the core IORT acpiview parser logic to a dedicated
function. Now, the pointer to the validation function is passed to the
IortNodePmcgParser[] ACPI_PARSER array.
This check does not affect the flow of IORT parsing and is limited to
a single table field in scope, therefore, it is better to keep it away
from the code responsible for traversing the table.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Split the Interrupt Controller Structure length validation in the
acpiview UEFI shell tool into two logical parts:
1. Ensuring MADT table parser forward progress.
2. Preventing MADT table buffer overruns.
Also, make the condition for infinite loop detection applicable to
all types of Interrupt Controller Structures (for all interrupt models
which can be represented in MADT). Check if the controller length
specified is shorter than the byte size of the first two fields
('Type' and 'Length') present in every valid Interrupt Controller
Structure.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
List ParseAcpi() function arguments one per line in order to make this
function call consistent with ParseAcpi() calls in other ACPI table
parsers.
Also, notify the user that XsdtAddress value of 0 results in RSDP
parsing being terminated and that the XSDT table will not be processed.
This effectively means that no more ACPI tables will be parsed because
of this RSDP table content error.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Remove a call to ParseAcpi() responsible for getting the XSDT table
length. This call is not needed because the ACPI table buffer length is
provided as an input argument to the ParseAcpiXsdt() function.
Modify remaining code to use the AcpiTableLength argument of the
ParseAcpiXsdt() function instead of a global static variable.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Modify the signature of the DumpGasStruct() function to include the
buffer length parameter and to return the number of bytes parsed by
the function.
This way it becomes possible to prevent buffer overruns when dumping
Generic Address Structure's (GAS) fields in the acpiview table
parsers.
Update all existing DumpGasStruct() calls in acpiview to add the
length argument.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2007
The following two PCI Capability Structure registers are updated as per
the PCI Base Specification Revision 4:-
(1) The PCI Device capability register 2(PCI_REG_PCIE_DEVICE_CAPABILITY2)
needs to be upgraded for the PCI features like -
LN system CLS (LnSystemCLS),
10b Tag completer/requester register fields
(TenBitTagCompleterSupported, TenBitTagRequesterSupported),
Emergency power reduction support and initialization requirement
(EmergencyPowerReductionSupported,
EmergencyPowerReductionInitializationRequired),
and FRS support (FrsSupported ).
(2) The PCI Device Control register 2(PCI_REG_PCIE_DEVICE_CONTROL2) needs
to be upgraded for the -
Emergency power reduction request enabling
(EmergencyPowerReductionRequest), and also the 10b Extended Tag
enabling (TenBitTagRequesterEnable).
The following two are defined as per the PCI Express Base Specification
Revision 2.1:-
(1) Defined macro definitions for all the ranges of Maximum Payload Sizes
and Maximum Read Request Sizes register fields
(2) Defined macro definitions for all the ranges of Completion Timeout
value.
Signed-off-by: Ashraf Javeed <ashraf.javeed@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
In commit 1fce963d89 we reduced the level of information printed
by PeCoffLoaderRelocateImageExtraAction() but we did not update the
similar PeCoffLoaderUnloadImageExtraAction() function.
PeCoffLoaderUnloadImageExtraAction() prints helpful debugger commands
for source level debugging. These messages should not be printed on the
EFI_D_ERROR level; they don't report errors. Change the debug level
(bitmask, actually) to DEBUG_LOAD | DEBUG_INFO, because the messages are
printed in relation to image loading, and they are informative.
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reported-by: Andrew Jones <drjones@redhat.com>
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Specify the firmware to use via the newer '-drive if=pflash' syntax
which allows specifying the raw format parameter. This
avoids warnings with newer version of QEMU.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
$ADD_QEMU_HDA was added because QEMU used to refuse to run without a
disk. Since newer versions run without any disks, remove it.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
This reverts commit 30f6148546.
Commit 30f6148546 causes a build failure, when building for IA32:
> UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c: In function
> 'PerformRemainingTasks':
> UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c:1440:9: error:
> 'mCpuSmmStaticPageTable' undeclared (first use in this function)
> if (mCpuSmmStaticPageTable) {
"mCpuSmmStaticPageTable" is an X64-only variable. It is defined in
"X64/PageTbl.c", which is not linked into the IA32 binary. We must not
reference the variable in such code that is linked into both IA32 and X64
builds, such as "PiSmmCpuDxeSmm.c".
We have encountered the same challenge at least once in the past:
- https://bugzilla.tianocore.org/show_bug.cgi?id=1593
- commit 37f9fea5b8 ("UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand
paging in SMM", 2019-04-04)
The right approach is to declare a new function in "PiSmmCpuDxeSmm.h", and
to provide two definitions for the function, one in "Ia32/PageTbl.c", and
another in "X64/PageTbl.c". The IA32 implementation should return a
constant value. The X64 implementation should return
"mCpuSmmStaticPageTable". (In the example named above, the functions were
SaveCr2() and RestoreCr2().)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: push revert immediately, due to build breakage that
would have been easy to catch before submitting the patch]
Commit c60d36b4d1
* UefiCpuPkg/SmmCpu: Block access-out only when static paging is used
updated page fault handler to treat SMM access-out as allowed
address when static paging is not used.
But that commit is not complete because the page table is still
updated in SetUefiMemMapAttributes() for non-SMRAM memory. When SMM
code accesses non-SMRAM memory, page fault is still generated.
This patch skips to update page table for non-SMRAM memory and
page table itself.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2018
Current FSP SEC_IDT_TABLE structure is not natural aligned:
typedef struct _SEC_IDT_TABLE {
EFI_PEI_SERVICES *PeiService;
UINT64 IdtTable[];
} SEC_IDT_TABLE;
Compiler will insert DWORD padding between 2 elements and
GetPeiServicesTablePointer() in early phase then always
returns padding data from stack, which was not reset to 0
in SecMain.
Solution is to align FSP SEC_IDT_TABLE structure to UefiCpuPkg
to have UINT64 as PeiService field and reset it to 0.
Test: Verified on internal platform and booting successfully
with FSP API mode.
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Enable multithreaded builds by default when building OvmfPkg
using build.sh.
This can drastically reduce build times. For example, on a
modern ThreadRipper system the time required to build decreases
from 3 minutes to 1 minute.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
This is a (very minor) optimization: `pwd` runs the command (even as a
built-in), whereas $PWD simply evaluates the value of the variable.
ALso, modern scripts should generally use $(...) to run commands,
instead of `...`.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Message-Id: <20190716165538.57960-1-rebecca@bsdio.com>
The BaseTools build feature introduced for TianoCore#1804 / in commit
1fa6699e6c ("BaseTools: Add a checking for Sources section in INF file",
2019-06-10) logs some (non-fatal) warnings about unlisted internal header
files. List those files explicitly.
Note: header files are added in lexicographical order only if the
underlying INF file already keeps the [Sources] and [LibraryClasses]
sections in lexicographical order. Otherwise, header files are added in
rough "logical" order.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The BaseTools build feature introduced for TianoCore#1804 / in commit
1fa6699e6c ("BaseTools: Add a checking for Sources section in INF file",
2019-06-10) logs some (non-fatal) warnings about unlisted internal header
files. List those files explicitly.
Note: header files are added in lexicographical order only if the
underlying INF file already keeps the [Sources] and [LibraryClasses]
sections in lexicographical order. Otherwise, header files are added in
rough "logical" order.
Cc: Jian Wang <jian.j.wang@intel.com>
Cc: Ting Ye <ting.ye@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
The BaseTools build feature introduced for TianoCore#1804 / in commit
1fa6699e6c ("BaseTools: Add a checking for Sources section in INF file",
2019-06-10) logs some (non-fatal) warnings about unlisted internal header
files. List those files explicitly.
Note: header files are added in lexicographical order only if the
underlying INF file already keeps the [Sources] and [LibraryClasses]
sections in lexicographical order. Otherwise, header files are added in
rough "logical" order.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
The BaseTools build feature introduced for TianoCore#1804 / in commit
1fa6699e6c ("BaseTools: Add a checking for Sources section in INF file",
2019-06-10) logs some (non-fatal) warnings about unlisted internal header
files. List those files explicitly.
Note: header files are added in lexicographical order only if the
underlying INF file already keeps the [Sources] and [LibraryClasses]
sections in lexicographical order. Otherwise, header files are added in
rough "logical" order.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2003
lstrip(parameter) do the match based on the char
in parameter but not only the whole parameter string.
In GenMake line 1082,
CmdSign.lstrip('/Fo') will strip the '/' or
'F' or 'o' on the left of CmdSign. This is not expected.
This patch is going to fix such issue.
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Remove redundant forward function declarations by repositioning
blocks of code. This way the code structure is consistent across
ACPI table parsers and the code becomes more concise.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Remove redundant forward function declarations by repositioning
blocks of code. This way the code structure is consistent across
ACPI table parsers and the code becomes more concise.
Replace multple use of literal values for GT Block Timer Frame
count/number validation with a macro definition.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Remove redundant forward function declarations by repositioning
blocks of code. This way the code structure is consistent across
ACPI table parsers and the code becomes more concise.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Remove redundant forward function declarations by repositioning
blocks of code. This way the code structure is consistent across
ACPI table parsers and the code becomes more concise.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Remove redundant forward function declarations by repositioning
blocks of code. This way the code structure is consistent across
ACPI table parsers and the code becomes more concise.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Remove redundant forward function declarations by repositioning
blocks of code. This way the code structure is consistent across
ACPI table parsers and the code becomes more concise.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Remove redundant forward function declarations by repositioning
blocks of code. This way the code structure is consistent across
ACPI table parsers and the code becomes more concise.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Add comment describing new F: and X: tags for associating maintainership
sections with specific filesystem paths, including wildcards.
Add global section associating *all* code with devel@edk2.groups.io,
with a default '*' F: tag directing all modifications that do not hit a
rule to the stewards.
Also tag all files in top directory as maintained by the stewards.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daude <philmd@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1972
AP calls CollectProcessorData() to collect processor info.
CollectProcessorData function finally calls PcdGetSize function to
get DynamicPCD PcdCpuFeaturesSetting value. PcdGetSize will use
PeiServices table which caused below assert info:
Processor Info: Package: 1, MaxCore : 4, MaxThread: 1
Package: 0, Valid Core : 4
ASSERT [CpuFeaturesPei] c:\projects\jsl\jsl_v1193\Edk2\MdePkg\Library
\PeiServicesTablePointerLibIdt\PeiServicesTablePointer.c(48):
PeiServices != ((void *) 0)
This change uses saved global pcd size instead of calls PcdGetSize to
fix this issue.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Chandana Kumar <chandana.c.kumar@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1968
The new VS2012 build failure is caused by 7a0df26.
xxx\registercpufeatureslib\dxeregistercpufeatureslib.c(258) :
warning C4701: potentially uninitialized local variable 'MpEvent' used
It is a false positive alarm.
MpEvent is assigned at line 238 and will be used at line 258, both
lines are controlled by "if (CpuFeaturesData->NumberOfCpus > 1)".
This patch initializes MpEvent to suppress incorrect compiler/analyzer
warnings.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The EDK II C Coding Standards Specification (v2.20) strongly discourages
variable declarations in nested block scope:
5 Source Files
5.4 Code File Structure
5.4.1 Scoping Rules
5.4.1.1 Scope
> Block (local) Scope
>
> [...]
>
> Data declarations may follow the opening brace of a compound statement,
> regardless of nesting depth, and before any code generating statements
> have been entered. Other than at the outermost block of a function body,
> this type of declaration is strongly discouraged.
Hoist such variable declarations in Base64Decode() to the outermost
function scope.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Cc: Zhichao Gao <zhichao.gao@intel.com>
Fixes: 35e242b698
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1980
Reported-by: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daude <philmd@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1937
EFI MM MP Protocol is defined in the PI 1.5 specification.
The MM MP protocol provides a set of functions to allow execution of
procedures on processors that have entered MM. This protocol has the
following properties:
1. The caller can invoke execution of a procedure on a processor, other
than the caller, that has also entered MM. Supports blocking and
non-blocking modes of operation.
2. The caller can invoke a procedure on multiple processors. Supports
blocking and non-blocking modes of operation.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Building with python3.8 shows a warning like:
SyntaxWarning: invalid escape sequence \(
GuidName = re.compile("\(GUID=[-a-fA-F0-9]+")
It seems harmless, but it's easy enough to fix: mark the string as
raw with the 'r' prefix like is used elsewhere in the file
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Fixes and assert seen when running ls under the shell. It appears the
assert was added in:
commit 99849a906e
ShellPkg/ls: Display the file time in local time.
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
ToolDefinitionFile is generated by PlatformAutoGen.ToolDefinition()
Code assume ToolDefinition is always called before using
ToolDefinitionFile, but in some cases, it's not true.
This patch is to fix this issue.
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The PL031 interrupt mask register (IMSC) is not very clearly documented
in the PL031 specification. However, bit 0 (RTCIMSC) indicates whether
interrupts are enabled, not disabled.
So before this commit, we were actually *enabling* interrupts for the RTC.
This patch changes the logic to instead disable interrupts when they
are not disabled already.
Signed-off-by: Alexander Graf <graf@amazon.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Per SDM, for IA-32e 4-KByte paging, there are four layers in the page
table structure:
1. PML4
2. Page-Directory-Pointer Table (PDPT)
3. Page-Directory (PD)
4. Page Table (PT)
The patch changes the local variable names and comments to use
"PML4", "PDPT", "PD", "PT" to better align to terms used in SDM.
There is no functionality impact for this change.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
This issue happens when using Structured PCD.
Build tool use set to store the cflags for compile PcdValueInit.c,
that is the order of cflags is disorder.
This patch make -U, /U flags appear before -D, /D
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Bob Feng <bob.c.feng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Commit 3c59d94637 ("BaseTools/FCE: Add a tool FCE") added a new tool
that is always built. Pre-existing tools locate the makefile includes
with relative paths, but FCE uses EDK_TOOLS_PATH, adding a new dependency
on having sourced edksetup.sh before building BaseTools.
Change FCE GNUmakefile to match other tools.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
(a) OvmfPkg first had to resolve the TpmMeasurementLib class -- for
SECURE_BOOT_ENABLE only -- when the DxeImageVerificationLib instance
became dependent on TpmMeasurementLib. For details, refer to commit
0d28d286bf ("OvmfPkg: resolve TpmMeasurementLib dependency
introduced in r14687", 2013-09-21).
(b) At the time, only one instance of TpmMeasurementLib existed, namely
DxeTpmMeasurementLib. This lib instance didn't do anything -- like it
was desirable for OVMF --, because OVMF didn't include any Tcg / TrEE
protocol implementations.
(c) In commit 308521b133 ("MdeModulePkg: Move TpmMeasurementLib
LibraryClass from SecurityPkg", 2015-07-01), TpmMeasurementLibNull was
introduced.
(d) In commit 285542ebbb ("OvmfPkg: Link AuthVariableLib for following
merged variable driver deploy", 2015-07-01), a TpmMeasurementLib
resolution became necessary regardless of SECURE_BOOT_ENABLE. And so
TpmMeasurementLib was resolved to TpmMeasurementLibNull in OVMF, but
only in the non-SECURE_BOOT_ENABLE case. This step -- possibly, the
larger series containing commit 285542ebbb -- missed an opportunity
for simplification: given (b), the DxeTpmMeasurementLib instance
should have been simply replaced with the TpmMeasurementLibNull
instance, regardless of SECURE_BOOT_ENABLE.
(e) In commit 1abfa4ce48 ("Add TPM2 support defined in trusted computing
group.", 2015-08-13), the TrEE dependency was replaced with a Tcg2
dependency in DxeTpmMeasurementLib.
(f) Starting with commit 0c0a50d6b3 ("OvmfPkg: include Tcg2Dxe module",
2018-03-09), OVMF would include a Tcg2 protocol implementation,
thereby satisfying DxeTpmMeasurementLib's dependency. With
TPM2_ENABLE, it would actually make sense to consume
DxeTpmMeasurementLib -- however, DxeTpmMeasurementLib would never be
used without SECURE_BOOT_ENABLE.
Therefore, we have the following four scenarios:
- TPM2_ENABLE + SECURE_BOOT_ENABLE: works as expected.
- Neither enabled: works as expected.
- Only TPM2_ENABLE: this build is currently incorrect, because
Variable/RuntimeDxe consumes TpmMeasurementLib directly, but
TpmMeasureAndLogData() will never reach the TPM because we link
TpmMeasurementLibNull into the variable driver. This is a problem from
the larger series containing (f).
- Only SECURE_BOOT_ENABLE: this build works as expected, but it is
wasteful -- given that the protocol database will never contain Tcg2
without TPM2_ENABLE, we should simply use TpmMeasurementLibNull. This is
a problem from (d).
Resolving TpmMeasurementLib to DxeTpmMeasurementLib as a function of
*only* TPM2_ENABLE, we can fix / optimize the last two cases.
v2:
- Amend the title and description suggested by Laszlo
- Move TpmMeasurementLib to the existed TPM2_ENABLE block
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20190704040731.5303-1-glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
ArmVirtPkg was created before we introduced the Package Reviewer (R:)
role in Maintainers.txt. However, we have always had an informal
agreement that if Ard or Laszlo is absent, I can review patches by
the still present one for going into ArmVirtPkg.
Plus, as one of the ArmPkg maintainers, it makes sense for me to have
better visibility of goings-on in ArmVirtPkg.
So let's formalise that, and add myself as a Package Reviewer, to be
CC:d on patches (while not taking up full maintainer responsibilities).
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Make the -h command line option a binary flag. Now, colour
highlighting is enabled whenever this flag is set (stateless),
instead of being dependent on previous acpiview command
invocations.
By removing the parameter required with the -h flag the command
line parsing logic becomes simpler.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Remove redundant whitespace characters at the beginning of the strings
describing IORT table field names.
When dumping ACPI table contents, the indentation level for printing
field names is controled using the 'Indent' argument to the 'ParseAcpi'
function. In the IORT acpiview parser, both 'Indent' and extra
whitespace characters are used for indentation, which results in
excess indentation.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
According to the acpiview documentation, the -v flag enables verbose
output and it is set on default.
Moreover, the acpiview UEFI shell tool dumps the same output with
and without this flag set.
Therefore this patch removes the superfluous -v flag from allowed
command line parameters.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The current documentation for the acpiview UEFI shell tool states
that the '-c' flag enables consistency checks on ACPI table data.
However, these checks are enabled anyway by default.
This patch keeps ACPI table validation as a default option, but it
makes it possible to turn ACPI table validation off by setting the
newly-introduced '-q' flag. Consequently, the '-c' flag is removed.
The remaining code changes in this patch make a number of consistency
checks optional (but enabled by default):
1. ACPI table field offset mismatch.
2. ACPI table field validation functions provided in the ACPI_PARSER
arrays.
3. Table checksum computation.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Print an extra newline character at the end DBG2 table parsing in order
to make the output resemble the one for other ACPI table parsers.
With this change, there is now a blank line between the DBG2 table dump
and the 'Table Statistics' section.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Move printing double newline character ('\n\n') from the beginning of
ACPI table checksum validation message to the end of the raw binary
data dump.
This way acpiview table dump looks similar regardless of whether Table
Checksum is validated or not.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Acpiview currently allows displaying help info by specifying both
-? and /? flags. This patch removes /? from valid command line
flags that can be passed to the acpiview tool, as this
flag is not used for such purpose in other UEFI shell commands.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Calling DisconnectController() on children isn't part of the job of
EFI_DRIVER_BINDING_PROTOCOL.Stop() as it only needs to deallocate
resources allocated in Start(). The disconnection will happen when
both DevicePath and XenBus protocols gets uninstalled.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20190701111403.7007-1-anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In XenBusDxe, the XenBusAddDevice() opens the gXenIoProtocolGuid on
behalf of child controllers. It is never closed and prevents us from
uninstalling the protocol.
Close it where we stop all the children in XenBusDxe->Stop().
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190701105012.25758-1-anthony.perard@citrix.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1678
Use the PcdPlatformRecoverySupport to control the function
of platform recovery in BDS.
First, set the variable's ("OsIndicationsSupported")
EFI_OS_INDICATIONS_START_PLATFORM_RECOVERY bit base on the pcd.
It would affect the variable "OsIndications".
While the platform does not support the platform recovery,
it is inappropriate to set a PlatformRecovery#### variable. So
skip setting the variable. But it should remain the behavior of
booting from a default file path (such as \EFI\BOOT\BOOTX64.EFI)
to be compatible with the previous version UEFI spec.
Add memory check before build platform default boot option. If
fail to allocate memory for the defualt boot file path, put the
system into dead loop to indicate it is unable to boot.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Turner <Michael.Turner@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1882
Implement support for GetOperatingParamters notify phase
in SdMmcHcDxe driver. GetOperatingParameters notify phase
is signaled before we start card detection and initialization.
Code has been updated for both eMMC and SD card controllers to
take into consideration those new parameters. Initialization process
has been divided into 2 steps. In the first step we bring the link
up to the point where we can get card identification data(Extended
CSD in eMMC case and SWITCH command response in SD card case). This
data is later used along with controller capabilities and operating
parameters passed in GetOperatingParameters phase to choose preferred
bus settings in GetTargetBusSettings function. Those settings are later
on to start bus training to high speeds. If user passes incompatible
setting with selected bus timing driver will assume it's standard behavior
with respect to that setting. For instance if HS400 has been selected as a
target bus timing due to card and controller support bus width setting of
4 and 1 bit won't be respected and 8 bit setting will be chosen instead.
Tests on Marvell boards were also performed by Marcin Wojtas
<mw@semihalf.com>:
https://edk2.groups.io/g/devel/message/42999
Board 1 (out of tree): SD - OK, MMC - OK
Board 2: (Armada80x0McBin): SD - OK, MMC - OK
Board 3: (Armada70x0Db): SD - problems, MMC - OK
Please note that the problem on Armada70x0Db SD devices are introduced by
adding new types of SD bus modes, a subsequent patch within edk2-platforms
repository will be proposed to address it.
(More details can be referred from the above link.)
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Regression-tested-by: Sumit Garg <sumit.garg@linaro.org>
https://bugzilla.tianocore.org/show_bug.cgi?id=1882
The new notify phase allows platform to configure additional
bus parameters in addition to parameters that can already be configured
with capability override. Specifically we allow to configure bus width,
clock frequency and driver strength. If platform doesn't wish to configure
some of the parameters it can left it on default values and driver will
assume it's standard behavior with respect to those parameters.
The definition of the SD_MMC_BUS_MODE has been extended to
incorporate SD card default speed and high speed.
Tests on Marvell boards were also performed by Marcin Wojtas
<mw@semihalf.com>:
https://edk2.groups.io/g/devel/message/42999
Board 1 (out of tree): SD - OK, MMC - OK
Board 2: (Armada80x0McBin): SD - OK, MMC - OK
Board 3: (Armada70x0Db): SD - problems, MMC - OK
Please note that the problem on Armada70x0Db SD devices are introduced by
adding new types of SD bus modes, a subsequent patch within edk2-platforms
repository will be proposed to address it.
(More details can be referred from the above link.)
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Regression-tested-by: Sumit Garg <sumit.garg@linaro.org>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1341
Since UFS specification requires the data buffer specified
in PRDT to be DWORD aligned in size we had a code in
UfsInitUtpPrdt that aligned the data buffer by rounding down
the buffer size to DWORD boundary. This meant that for SCSI
commands that wanted to perform unaligned data transfer(such as
SENSE command) we specified to small buffer for the data to fit
and transfer was aborted. This change introduces code that allocates
auxiliary DWORD aligned data buffer for unaligned transfer. Device
transfers data to aligned buffer and when data transfer is over driver
copies data from aligned buffer to data buffer passed by user.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Port the [LibraryClasses], [PcdsFixedAtBuild] and [Components] settings
that are related to NETWORK_TLS_ENABLE from OvmfPkg to ArmVirtPkg.
ArmVirtXen is not modified because it doesn't include the edk2 network
stack.
(This change is now simpler than it would have been when TianoCore#1009
was originally filed, due to ArmVirtPkg consuming the NetworkPkg include
fragments meanwhile, from TianoCore#1293 / commit 157a3b1aa50f.)
The usage hints from "OvmfPkg/README", section "HTTPS Boot", apply.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Lin <glin@suse.com>
Cc: Guillaume GARDET <guillaume.gardet@arm.com>
Cc: Julien Grall <julien.grall@arm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1009
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Guillaume Gardet <guillaume.gardet@arm.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Tested-by: Gary Lin <glin@suse.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1834
1)Add arguments "--embedded-driver" to support embedded driver
in command line.
2)Add arguments "--update-image-index" to identify ImageIndex
within the device in command line.
3)Add arguments "-j JSONFILE" to support multiple payloads and
embedded drivers with JSON file.
The update is in a backwards compatible manner, so all command
line options to support single payload are still supported. But
all the options associated with multiple payloads should be
provided in a JSON file.
Cc: Bob Feng <bob.c.feng@intel.com>
Signed-off-by: Eric Jin <eric.jin@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1934
0x0 MicrocodeBegin MicrocodeEntry MicrocodeEnd 0xffffffff
|--------------|---------------|---------------|---------------|
valid TotalSize
TotalSize is only valid between 0 and (MicrocodeEnd - MicrocodeEntry).
So add '(UINTN)MicrocodeEntryPoint > (MAX_ADDRESS - TotalSize)' before
'((UINTN)MicrocodeEntryPoint + TotalSize) > MicrocodeEnd' to make sure
((UINTN)MicrocodeEntryPoint + TotalSize) wouldn't overflow.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
In current implementation we are checking for device presence every
time we execute UIC command. To make UfsExecUicCommands more generic
checking device presence has been moved to UfsDeviceDetection.
Signed-off-by: Mateusz Albecki <mateusz.albecki@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1844
The commit will remove the below modules from PcAtChipsetPkg:
* PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
* PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
* PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf
They are considered legacy framework components and will no longer be used
after the removal of IntelFramework[Module]Pkg.
Also, the unused (after the modules being removed) PCDs will be deleted in
package level DEC/UNI files.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1617
This driver implements a common checker, verifier and reporter which is
independent of hardware based root-of-trust.
Usually the hardware based root-of-trust will not verify all BIOS but
part of it. For example, Boot Guard will only verify IBB segment. The IBB
needs to verify other part of BIOS, i.e. other FVs to transfer control to
from IBB. This driver plays the role in IBB to verify FVs not covered by
hardware root-of-trust to make sure integrity of the chain of trust.
To be hardware/platform independent, PPI
gEdkiiPeiFirmwareVolumeInfoStoredHashFvPpiGuid
is introduced for platform to pass digest information to this driver.
This PPI should include all information needed to verify required FVs in
required boot mode.
struct _EDKII_PEI_FIRMWARE_VOLUME_INFO_STORED_HASH_FV_PPI {
FV_HASH_INFO HashInfo;
UINTN FvNumber;
HASHED_FV_INFO FvInfo[1];
};
To avoid TOCTOU issue, all FVs to be verified will be copied to memory
before hash calculation. That also means this driver has to be run after
permanent memory has been discovered.
For a measured boot, this driver will install
gEdkiiPeiFirmwareVolumeInfoPrehashedFvPpiGuid
to report digest of each FV to TCG driver.
For a verified boot, this driver will verify the final hash value
(calculated from the concatenation of each FV's hash) for indicated
FVs against the hash got from platform/hardware.
If pass, it will build EFI_HOB_TYPE_FV (consumed by DXE core) and/or
install gEfiPeiFirmwareVolumeInfoPpiGuid (consumed by PEI core), and
then report status code PcdStatusCodeFvVerificationPass.
If fail, it just report status code PcdStatusCodeFvVerificationFail
and go to dead loop if status report returns.
The platform can register customized handler to process pass and fail
cases differently.
Currently, this driver only supports hash (sha256/384/512) verification
for the performance consideration.
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: "Hernandez Beltran, Jorge" <jorge.hernandez.beltran@intel.com>
Cc: Harry Han <harry.han@intel.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1617
gEdkiiPeiFirmwareVolumeInfoStoredHashFvPpiGuid should be installed by
platform to pass FV hash information to the common FV verify/report
driver, in which the hash value will be calculated again based on the
information fed in and then verified.
The information passed in this PPI include:
- FVs location in flash and length
- Hash values for different boot mode
The hash value must be calculated in following way (if 3 FVs to calc):
FV1 -> Hash1
FV2 -> Hash2
FV3 -> Hash3
Hash1 + Hash2 + Hash3 -> HashAll
Only HashAll is stored in this PPI. The purposes for this algorithm
are two:
1. To report each FV's hash to TCG driver and verify HashAll at the
same time without the burden to calculate the hash twice;
2. To save hash value storage due to potential hardware limitation
Different boot mode may have its own hash value so that each mode can
decide which FV will be verified. For example, for the sake of performance,
S3 may choose to skip some FVs verification and normal boot will verify
all FVs it concerns.
So in this PPI, each FV information has flag to indicate which boot mode
it will be taken into hash calculation.
And if multiple hash values passed in this PPI, each has a flag to indicate
which boot mode it's used for. Note one hash value supports more than one
boot modes if they're just the same.
PcdStatusCodeFvVerificationPass and PcdStatusCodeFvVerificationFail are
introduced to report status back to platform, and platform can choose how
to act upon verification success and failure.
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: "Hernandez Beltran, Jorge" <jorge.hernandez.beltran@intel.com>
Cc: Harry Han <harry.han@intel.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Chao Zhang <chao.b.zhang@intel.com>
Mostly, this is only necessary for devices that the CSM might have
native support for, such as VirtIO and NVMe; PciBusDxe will already
degrade devices to 32-bit if they have an OpROM.
However, there doesn't seem to be a generic way of requesting PciBusDxe
to downgrade specific devices.
There's IncompatiblePciDeviceSupportProtocol but that doesn't provide
the PCI class information or a handle to the device itself, so there's
no simple way to just match on all NVMe devices, for example.
Just leave gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size set to zero for
CSM builds, until/unless that can be fixed.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190626113742.819933-5-dwmw2@infradead.org>
QemuVideoDxe installs its own legacy INT 10h handler for the benefit of
systems like Windows 2008r2 which attempt to use INT 10h even when booted
via EFI.
This interacts extremely badly with a CSM actually attempting to install
a real video BIOS.
The last thing done before invoking a legacy OpROM is to call INT 10h to
set a plain text mode. In the case where it's the video BIOS OpROM being
loaded, INT 10h will normally point to an iret stub in the CSM itself.
Unless QemuVideoDxe has changed INT10h to point to a location in the
0xC0000 segment that it didn't allocate properly, so the real OpROM has
been shadowed over them top of it, and the INT 10h vector now points to
some random place in the middle of the newly-shadowed OpROM.
Don't Do That Then. QemuVideoDxe doesn't do any acceleration and just
sets up a linear framebuffer, so we don't lose much by just
unconditionally using BiosVideoDxe instead when CSM is present.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190626113742.819933-4-dwmw2@infradead.org>
Iterate over the available block devices in much the same way as
BdsLibEnumerateAllBootOption() does, but limiting to those devices
which are PCI-backed, which can be represented in the BbsTable.
One day we might need to extend the BbsTable to allow us to distinguish
between different NVMe namespaces on a device.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190626113742.819933-3-dwmw2@infradead.org>
REF: https://github.com/tianocore/tianocore.github.io/wiki/
UEFI-Capsule-on-Disk-Introducation
CoDCheckCapsuleOnDiskFlag() is to check if CapsuleOnDisk flag in
"OsIndications" Variable is enabled. It is used to indicate whether
capsule on disk is provisioned in normal boot path.
CoDClearCapsuleOnDiskFlag() is to to clear CapsuleOnDisk flags,
including "OsIndications" and "BootNext" variable.
CoDRelocateCapsule() is to relocate the capsules from EFI system
partition. Depends on PcdCapsuleInRamSupport, there are two solutions
to relocate the capsule on disk images:
When Capsule In Ram is supported, the Capsule On Disk images are
relocated into memory, and call UpdateCapsule() service to deliver
the capsules.
When Capsule In Ram is not supported, the Capsule On Disk images are
relocated into a temp file which will be stored in root directory on
a platform specific storage device. CapsuleOnDiskLoadPei PEIM will
retrieve the capsules from the relocation temp file and report
capsule hobs for them.
CoDRemoveTempFile() is to remove the relocation temp file in the next
boot after capsules are processed.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Chao B Zhang <chao.b.zhang@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
REF: https://github.com/tianocore/tianocore.github.io/wiki/
UEFI-Capsule-on-Disk-Introducation
This patch will add Capsule On Disk related definition, including
GUID, PPI and PCDs:
The Capsule On Disk Name GUID indicates the capsule is to store
Capsule On Disk file names.
The Pei Capsule On Disk PPI provides service to retrieve capsules
from Capsule On Disk temp relocation file on mass storage devices
and create capsule hob for these capsules.
Pei Boot In CapsuleOnDisk Mode Ppi indicates current boot mode is
capsule on disk mode.
PcdCapsuleOnDiskSupport is used to enable/disable Capsule On Disk.
PcdCapsuleInRamSupport is used to enable/disable Capsule In Ram.
PcdCoDRelocationFileName specifies the Capsule On Disk temp
relocation file name.
PcdCodRelocationDevPath specifies platform specific device to store
Capsule On Disk temp relocation file.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Chao B Zhang <chao.b.zhang@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1840
1. Introduce an internal header file to put definitions in it.
2. Add missing '\n' in usage.
3. Fix the dead loop of CapsuleApp -L.
4. Fix the bug that CapsuleApp -OD cannot perform capsules in sub-
folder.
5. Optimize the handling for option -NR and -OD to support both
'CapsuleApp <Capsule> -OD -NR' and 'CapsuleApp <Capsule> -NR -OD'.
6. Check if Capsule-On-Disk is supported by "OsIndicationsSupported"
variable firstly before processing capsules. If not supported, prompt
an error message and quit the process.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Chao B Zhang <chao.b.zhang@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1879
This commit will add the definitions of Nvm Express PassThru PPI.
This PPI will provide services that allow NVM commands to be sent
to NVM Express devices during PEI phase.
More specifically, the PPI will provide services to:
* Sends an NVM Express Command Packet to an NVM Express controller
or namespace (by service 'PassThru');
* Get the list of the attached namespaces on a controller
(by services 'GetNextNameSpace');
* Get the identification information (DevicePath) of the underlying
NVM Express host controller (by service 'GetDevicePath').
Signed-off-by: Maggie Chu <maggie.chu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Re-run process_files.py to generate OpensslLib[Crypto].inf.
CryptoPkg/Library/Include/openssl/opensslconf.h is coped from OpenSSL,
So keep the CR/LF style like OpenSSL source file.
Cc: Jian J Wang <jian.j.wang@intel.com>
Signed-off-by: Xiaoyu Lu <xiaoyux.lu@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Capsule-
on-Disk-Introducation
CoDCheckCapsuleOnDiskFlag() is to check if CapsuleOnDisk flag in
"OsIndications" Variable is enabled. It is used to indicate whether
capsule on disk is provisioned in normal boot path.
CoDClearCapsuleOnDiskFlag() is to to clear CapsuleOnDisk flags,
including "OsIndications" and "BootNext" variable.
CoDRelocateCapsule() is to relocate the capsules from EFI system
partition. Depends on PcdCapsuleInRamSupport, there are two solutions
to relocate the capsule on disk images:
When Capsule In Ram is supported, the Capsule On Disk images are
relocated into memory, and call UpdateCapsule() service to deliver
the capsules.
When Capsule In Ram is not supported, the Capsule On Disk images are
relocated into a temp file which will be stored in root directory on
a platform specific storage device. CapsuleOnDiskLoadPei PEIM will
retrieve the capsules from the relocation temp file and report
capsule hobs for them.
CoDRemoveTempFile() is to remove the relocation temp file in the next
boot after capsules are processed.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Chao B Zhang <chao.b.zhang@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1840
1. Add missing '\n' in usage.
2. Fix the dead loop of CapsuleApp -L.
3. Fix the bug that CapsuleApp -OD cannot perform capsules in sub-
folder.
4. Optimize the handling for option -NR and -OD to support both
'CapsuleApp <Capsule> -OD -NR' and 'CapsuleApp <Capsule> -NR -OD'.
5. Check if Capsule-On-Disk is supported by "OsIndicationsSupported"
variable firstly before processing capsules. If not supported, prompt
an error message and quit the process.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Chao B Zhang <chao.b.zhang@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Capsule-
on-Disk-Introducation
This patch will add Capsule On Disk related definition, including
GUID, PPI and PCDs:
The Capsule On Disk Name GUID indicates the capsule is to store
Capsule On Disk file names.
The Pei Capsule On Disk PPI provides service to retrieve capsules
from Capsule On Disk temp relocation file on mass storage devices
and create capsule hob for these capsules.
Pei Boot In CapsuleOnDisk Mode Ppi indicates current boot mode is
capsule on disk mode.
PcdCapsuleOnDiskSupport is used to enable/disable Capsule On Disk.
PcdCapsuleInRamSupport is used to enable/disable Capsule In Ram.
PcdCoDRelocationFileName specifies the Capsule On Disk temp
relocation file name.
PcdCodRelocationDevPath specifies platform specific device to store
Capsule On Disk temp relocation file.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Chao B Zhang <chao.b.zhang@intel.com>
Signed-off-by: Wei6 Xu <wei6.xu@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Chao B Zhang <chao.b.zhang@intel.com>
The ACPI 6.3 specification introduces a 'SPE overflow
Interrupt' field as part of the GICC structure.
Update the MADT parser to decode this field and validate
the interrupt ID used.
References:
- ACPI 6.3 Specification - January 2019
- Arm Generic Interrupt Controller Architecture Specification,
GIC architecture version 3 and version 4, issue E
- Arm Server Base System Architecture 5.0
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
The comments describes the device as being 32-bit:
"the maximum time span is just over 136 years"
then uses a UINTN to hold the value.
Change to UINT32 so we don't get different behaviour for different architectures.
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1894
Basetool need a CopyFileOnChange() function to avoid cache
file writing race in multi-thread build. Some platforms
build fail with file IO writing race issue when the
build cache is enabled to store cache files in multi-threads.
This is because common same library cache files (e.g. some
libs in MdePkg) can be stored by many different driver modules'
build threads at same time. Current build cache need a function
to check whether the same cache file already exist, and only
copy source file if it is different from the destination file.
This patch introduces an atomic copy function to avoid duplicated
cache files copy.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Christian Rodriguez <christian.rodriguez@intel.com>
Signed-off-by: Steven Shi <steven.shi@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=1895
Build cache cannot store cache for the same library modules
in different arch together. E.g. Both the below IA32 and X64
arch BaseLib caches should exist after build Ovmf3264, but now
only the one in X64 arch exist.
The reason is the current Basetool use a set() to same all
library AutoGen objects, but the different arch lib AutoGen
objects have same __hash_ value which comes from the lib
MetaFile(The path of module file):
def __hash__(self):
return hash(self.MetaFile)
So the different arch lib AutoGen objects are duplicated one
to the set() and only one can exist. This is why the Basetool
can only store one arch cache for library.
This patch adds the arch string into the PlatformAutoGen and
ModuleAutoGen __hash_ definitions and ensure the different
platform and module AutoGen objects have different __hash_ values.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Christian Rodriguez <christian.rodriguez@intel.com>
Signed-off-by: Steven Shi <steven.shi@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1867
Current build cache cannot store the cache for library package.
build -p MdePkg\MdePkg.dsc -a IA32 -b DEBUG -t VS2015x86 --hash
--binary-destination=BinCache
After build, the expected result is the BinCache folder is generated
and the MdePkg build cache files (e.g. .hash and .lib) are stored in
the BinCache folder. But the BinCache folder is not generated at all.
This patch is going to fix that issue.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Zhiju.Fan <zhijux.fan@intel.com>
Signed-off-by: Steven Shi <steven.shi@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
SERIAL_DXE_FILE_GUID is now defined in MdeModulePkg as
EDKII_SERIAL_PORT_LIB_VENDOR_GUID, simply use it.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Message-Id: <20190606131459.1464-3-anthony.perard@citrix.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
[lersek@redhat.com: drop "from MdeModulePkg" from the subject]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
The DX register is supposed to contain the required alignment for the
allocation. It was zero, and SeaBIOS doesn't (well, didn't) cope well
with that. Set it appropriately.
Also set BX to indicate the regions it's OK to allocate in too. That
wasn't being initialised and was just using whatever the previous user
of the structure had left there.
Finally, actually return an error if the allocation fails. Instead of
going all the way through into the CSM and just letting it have a bogus
pointer to the E820 data.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
This commit will update the driver's INF file to:
A) Assign a new file GUID;
B) Consume the PCDs duplicated in OvmfPkg DEC file;
C) Remove the IntelFramework[Module]Pkg DEC file dependency.
Please note that a subsequent commit (final patch of the series) will:
Replace the use of LegacyBiosDxe in IntelFrameworkModulePkg with the one
copied in OvmfPkg within DSC/FDF files.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
This commit will update the driver's INF file to:
A) Assign a new file GUID;
B) Consume the PCDs duplicated in OvmfPkg DEC file;
C) Remove the IntelFramework[Module]Pkg DEC file dependency.
Please note that a subsequent commit (final patch of the series) will:
Replace the use of VideoDxe in IntelFrameworkModulePkg with the one copied
in OvmfPkg within DSC/FDF files.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
This commit will add the PCD definitions consumed by the duplicated
drivers:
* VideoDxe
* LegacyBiosDxe
into the OvmfPkg DEC file.
Please note that, instead of adding these PCDs under section:
[PcdsFixedAtBuild, PcdsDynamic, PcdsDynamicEx, PcdsPatchableInModule]
as in IntelFrameworkModulePkg.dec file, they are added in section:
[PcdsFixedAtBuild]
in OvmfPkg.dec instead.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1412
Original logic:
Connect the graphics device -> connect it as graphics consoles
and initialize its parameters(Mode = -1, invalid) -> connect it
as console spliter and add the device to the list(use SetMode to
set mode to the user defined mode or the best mode the devices
supported if the mode is invalid. *clear the screen at this phase*)
Changed logic:
Connect the graphics device -> connect it as graphics consoles
and initialize its parameters(initialize the mode to the user
defined mode or the best mode. *directly set the mode value without
using SetMode, that would not clear the screen) -> connect it as
console spliter and add the device to the list(use SetMode to set
mode to the user defined mode or the best mode the devices supported
if the mode is invalid. *now the mode is already set, so it would
not clear the screen*).
Also remove the section of SetMode for debug version.
Impact: as the text mode may not be an invalid value, the SetMode
may have no chance to be called during reconnect the graphics device.
That means the screen may not be cleaned after finishing reconnect
operation. There is one common condition: shell command "recoonect -r".
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Michael Turner <Michael.Turner@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Before adding the git environment initialization script, add the
following files that will be pointed to after running said script:
- BaseTools/Conf/diff.order
- BaseTools/Conf/gitattributes
Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
When assigning a physical PCIe device to a QEMU/KVM guest, PciBusDxe may
find that the extended config space is not (fully) implemented. In
LocatePciExpressCapabilityRegBlock(), "CapabilityEntry" may be read as
0xFFFF_FFFF at a given config space offset, after which the loop gets
stuck spinning on offset 0xFFC (the read at offset 0xFFC returns
0xFFFF_FFFF most likely as well).
Another scenario (not related to virtualization) for triggering the above
is when a Conventional PCI bus -- exposed by a PCIe-to-PCI bridge in the
topology -- intervenes between a PCI Express Root Port and a PCI Express
Endpoint. The Conventional PCI bus limits the accessible config space of
the PCI Express Endpoint, even though the endpoint advertizes the PCI
Express capability. Here's a diagram, courtesy of Alex Williamson:
[PCIe Root Port]--[PCIe-to-PCI]--[PCI-to-PCIe]--[PCIe EP]
->| |<- Conventional PCI bus
Catch reads of 0xFFFF_FFFF in LocatePciExpressCapabilityRegBlock(), and
break out of the scan with a warning message. The function will return
EFI_NOT_FOUND.
Cc: Alex Williamson <alex.williamson@redhat.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Changed the line endings to DOS line endings for
DynamicTablesPkg/DynamicTablesPkg.dsc
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
The ACPI 6.3 specification adds support for describing
ARMv8.1 EL2 virtual timers. Update GTDT Generator
to extend this support.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The PPTT generator uses the configuration manager protocol to
obtain information about platform's processor topology and caches.
This data is then used to generate the PPTT table.
The table generator supports ACPI 6.3, PPTT table revision 2.
The dynamic PPTT generator also carries out extensive input
validation which includes cycle detection and MADT-PPTT
cross-validation. A number of architectural compliance checks
are also performed.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1842
According to the discussion at:
https://edk2.groups.io/g/devel/topic/30918343#38093
For OVMF, we keep both ISA stacks:
* The legacy one in PcAtChipsetPkg/IntelFrameworkModulePkg
* The Sio bus based OVMF-specified one introduced by commit a5cc178aeb
for a period of time (includes 1 stable tag: edk2-stable201905). And we
also keep the Sio bus based OVMF-specified stack as the default one (via a
build option 'USE_LEGACY_ISA_STACK') to validate its stability.
This commit will propose to drop the legacy ISA stack from OVMF and remove
the usage of the build flag 'USE_LEGACY_ISA_STACK' at the same time. This
is considered as a preparation for the removal of
PcAtChipsetPkg/IsaAcpiDxe & IntelFrameworkModulePkg.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The Dynamic Tables Framework now supports generating Multiple APIC
Description Table (MADT) revision 5 for ARM platforms while maintaining
backward-compatibility with ACPI 6.2.
The relevant change is the enablement of the Statistical Profiling
Extension (SPE).
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Check for duplicate frame numbers when populating the GT Block Timer
Frames inside the GTDT table generator.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Check for duplicate ACPI Processor UIDs when populating the GIC CPU
(GICC) Interface structures inside the MADT table generator.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Added generic function for detecting duplicate values in an array.
Also defined a function prototype to test if two objects are equal.
The prototype is used as an argument to the 'FindDuplicateValues'
function.
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Added code to check if the Generic Timer Block Structure's frame number
provided by the platform repository is within the allowed range (0-7).
References:
- ACPI 6.2 Errata A, Table 5-122, September 2017
Signed-off-by: Krzysztof Koch <krzysztof.koch@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
The ACPI 6.3 specification introduces support to describe
the ARMv8.1 virtual EL2 timers. This patch updates the GTDT parser
of acpiview to decode the EL2 virtual timer fields.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Alexei Fedorov <Alexei.Fedorov@arm.com>
Reviewed-by: Zhichao Gao <zhichao.gao@intel.com>
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1765
If RAW FFS File Rule has no section for its data.For RAW FFS File,
directly call GenFfs tool to generate FFS file.
Ffs Rule:
[Rule.Common.USER_DEFINED.MicroCode]
FILE RAW = $(NAMED_GUID) {
$(INF_OUTPUT)/$(MODULE_NAME).bin
}
[Rule.Common.USER_DEFINED.LOGO]
FILE RAW = $(NAMED_GUID) {
|.bmp
}
As shown in the rule above,if SectionType and FileType not defined,
FFS files are generated directly, and no other type of file is
generated.
The patch is to make the BaseTools support these two rules
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Signed-off-by: Zhiju.Fan <zhijux.fan@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
The patch fixes the bug that the memory under 1MB is modified by
firmware in S3 boot.
Root cause is a racing condition in MpInitLib:
1. BSP: WakeUpByInitSipiSipi is set by NotifyOnS3SmmInitDonePpi()
2. BSP: WakeUpAP() wakes all APs to run certain procedure.
2.1. AllocateResetVector() uses <1MB memory for wake up vector.
2.1. FillExchangeInfoData() resets NumApsExecuting to 0.
2.2. WaitApWakeup() waits AP to clear WAKEUP_AP_SIGNAL.
3. AP: ApWakeupFunction() clears WAKEUP_AP_SIGNAL to inform BSP.
5. BSP: FreeResetVector() restores the <1MB memory
4. AP: ApWakeupFunction() calls the certain procedure.
4.1. NumApsExecuting is decreased.
#4.1 happens after the 1MB memory is restored so the result is
memory below 1MB is changed by #4.1
It happens only when the AP executes procedure a bit longer.
AP returns back to ApWakeupFunction() from procedure after
BSP restores the <1MB memory.
Since NumApsExecuting is only used when InitFlag == ApInitConfig
for counting the processor count.
The patch moves the NumApsExecuting decrease to the path when
InitFlag == ApInitConfig.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Cc: Nandagopal Sathyanarayanan <nandagopal.sathyanarayanan@intel.com>
NumApsExecuting is only used when InitFlag == ApInitConfig for
counting the processor count.
The patch changes Ia32 version of waking up vector assembly code
to align to x64 version of waking up vector assembly code.
After the change both versions of waking up vector increase
NumApsExecuting when InitFlag == ApInitConfig.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1810
This patch covers two problems.
1. Current code gets CPUID_THERMAL_POWER_MANAGEMENT in
ClockModulationInitialize() and uses its ECMD bit for all processors.
But ClockModulationInitialize() is only executed by BSP, that means
the bit is just for BSP.
It may have no functionality issue as all processors may have same
bit value in a great possibility. But for good practice, the code
should get CPUID_THERMAL_POWER_MANAGEMENT in ClockModulationSupport
(executed by all processors), and then use them in
ClockModulationInitialize() for all processors.
We can see that Aesni.c (and others) have used this good practice.
2. Current code uses 3 CPU_REGISTER_TABLE_WRITE_FIELD for
MSR_IA32_CLOCK_MODULATION in ClockModulationInitialize(), they can
be reduced to 1 CPU_REGISTER_TABLE_WRITE64 by getting
MSR_IA32_CLOCK_MODULATION for all processors in
ClockModulationSupport() and then update fields for register table
write in ClockModulationInitialize().
We may argue that there may be more times of MSR_IA32_CLOCK_MODULATION
getting. But actually the times of MSR_IA32_CLOCK_MODULATION getting
could be also reduced.
The reason is in ProgramProcessorRegister() of CpuFeaturesInitialize.c,
AsmMsrBitFieldWrite64 (AsmReadMsr64 + AsmWriteMsr64) will be used for
CPU_REGISTER_TABLE_WRITE_FIELD, and AsmWriteMsr64 will be used for
CPU_REGISTER_TABLE_WRITE64.
The times of MSR accessing could be reduced with this patch.
Without the patch:
3 CPU_REGISTER_TABLE_WRITE_FIELD (in ClockModulationInitialize)
==> 3 AsmMsrBitFieldWrite64
==> 3 AsmReadMsr64 + 3 AsmWriteMsr64
With the patch:
1 AsmReadMsr64 (in ClockModulationSupport) +
1 CPU_REGISTER_TABLE_WRITE64 (in ClockModulationInitialize)
==> 1 AsmWriteMsr64
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Chandana Kumar <chandana.c.kumar@intel.com>
Cc: Kevin Li <kevin.y.li@intel.com>
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1829
There will be ASSERT if LMCE is supported as below.
DXE_ASSERT!: [CpuFeaturesDxe]
XXX\UefiCpuPkg\Library\CpuCommonFeaturesLib\MachineCheck.c (342):
ConfigData != ((void *) 0)
The code should get Config Data and FeatureControlGetConfigData
could be used.
This issue is there since the code was added at the commit below.
Revision: 3d6275c113
Date: 2017/8/4 8:46:41
UefiCpuPkg CpuCommonFeaturesLib: Enable LMCE feature.
The commits below are also related to move the code.
Revision: 0233871442
Date: 2017/9/1 10:12:38
UefiCpuPkg/Lmce.c Remove useless file.
Revision: 306a5bcc6b
Date: 2017/8/17 11:40:38
UefiCpuPkg/CpuCommonFeaturesLib: Merge machine check code to same file.
So, the code may not be tested at all on a platform
that supports LMCE.
BTW: A typo in LmceInitialize is also fixed.
The typo is introduced by the commit below.
Revision: d28daaddb3
Date: 2018/10/17 9:24:05
UefiCpuPkg/CpuCommonFeaturesLib: Register MSR base on scope Info.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Chandana Kumar <chandana.c.kumar@intel.com>
Cc: Kevin Li <kevin.y.li@intel.com>
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1808
In current code, the values of TopaEntryPtr->Uint64 for TopaTable
and the values of OutputBaseReg.Uint64 and OutputMaskPtrsReg.Uint64
to register table write for RTIT_OUTPUT_BASE and RTIT_OUTPUT_MASK_PTRS
are not been initialized in whole. For example, the reserved bits in
OutputBaseReg.Uint64 are random that will cause GP fault like below
when SetProcessorRegister (in CpuFeaturesInitialize.c) sets register
based on register table.
!!!! X64 Exception Type - 0D(#GP - General Protection)
CPU Apic ID - 00000000 !!!!
ExceptionData - 0000000000000000
RIP -0000000064D69576, CS -0000000000000038, RFLAGS -0000000000010246
RAX -000000006B9F1001, RCX -0000000000000560, RDX -0000000000000000
RBX -0000000064EECA18, RSP -000000006CB82BA0, RBP -0000000000000008
RSI -0000000080000000, RDI -0000000000000011
R8 -000000006B9493D0, R9 -0000000000000010, R10 -00000000000000FF
R11 -000000006CB82A50, R12 -0000000064D70F50, R13 -0000000066547050
R14 -0000000064E3E198, R15 -0000000000000000
DS -0000000000000030, ES -0000000000000030, FS -0000000000000030
GS -0000000000000030, SS -0000000000000030
CR0 -0000000080010013, CR2 -0000000000000000, CR3 -000000006C601000
CR4 -0000000000000628, CR8 -0000000000000000
DR0 -0000000000000000, DR1 -0000000000000000, DR2 -0000000000000000
DR3 -0000000000000000, DR6 -00000000FFFF0FF0, DR7 -0000000000000400
GDTR -000000006B8CCF18 0000000000000047, LDTR -0000000000000000
IDTR -000000006687E018 0000000000000FFF, TR -0000000000000000
FXSAVE_STATE -000000006CB82800
And current code gets MSR_IA32_RTIT_CTL, MSR_IA32_RTIT_OUTPUT_BASE and
MSR_IA32_RTIT_OUTPUT_MASK_PTRS in ProcTraceInitialize() and uses their
values for all processors. But ProcTraceInitialize() is only executed
by BSP, that means the values just for BSP. For good practice, the code
should get MSR_IA32_RTIT_CTL, MSR_IA32_RTIT_OUTPUT_BASE and
MSR_IA32_RTIT_OUTPUT_MASK_PTRS in ProcTraceSupport (executed by all
processors), and then use them in ProcTraceInitialize() for all
processors. This can also resolve the issue that the values of
OutputBaseReg.Uint64 and OutputMaskPtrsReg.Uint64 are not been
initialized in whole.
For TopaEntryPtr->Uint64, this patch updates code to initialize it
in whole explicitly by TopaEntryPtr->Uint64 = 0 before updating its
fields.
At the same time, this patch also eliminates the ProcTraceSupported
field in PROC_TRACE_PROCESSOR_DATA and the TopaMemArrayCount field in
PROC_TRACE_DATA.
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Chandana Kumar <chandana.c.kumar@intel.com>
Cc: Kevin Li <kevin.y.li@intel.com>
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
The status code reporting functionality in PrePiLib is never invoked
so let's just remove it.
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Query the supported attributes firstly, then bitwise AND (&) both VGA_IO
and VGA_IO_16. Since the supported attributes should only have one of
VGA_IO or VGA_IO_16 set, the result of bitwise AND (&) is either VGA_IO
or IO_16. Then the result can be passed to PciIo->Attributes() to set the
attributes.
Device driver should consider both since the mReserveVgaAliases in
PciBusDxe driver is default FALSE(implies that device driver can only set
VGA_IO_16 to PCI_ROOT_BRIDGE), and Platform code may not return
EFI_RESERVE_VGA_IO_ALIAS in GetPlatformPolicy of PciPlatformProtocol to
make mReserveVgaAliases become TRUE(implies that device driver can only
set VGA_IO to PCI_ROOT_BRIDGE), Currently OvmfPkg doesn't have problem
due to it has hard code value for PCI_ROOT_BRIDGE's attributes field, so
an IO access by PciIoProtocol will be successed due to
RootBridgeIoCheckParameter of PciRootBridgeIo.c will always get pass
result for legacy IO access.
Usually the attributes field of PCI_ROOT_BRIDGE should be 0, in that case
it will have issue since the VGA_IO may not be able to be enabled, then
IO access by PciIoProtocol will be failed, hence the QemuVideoDxe driver
will not work fine.
Signed-off-by: Marc Chen <marc.w.chen@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1880
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190606074237.81492-1-marc.w.chen@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2019-06-06 12:27:52 +02:00
1857 changed files with 82665 additions and 210652 deletions
1. A supported toolchain (others might work but this is what is tested and validated)
* Windows 10:
* VS 2017 or VS 2019
* Windows SDK (for rc)
* Windows WDK (for capsules)
* Ubuntu 16.04
* GCC5
* Easy to add more but this is the current state
2. Python 3.7.x or newer on path
3. git on path
4. Recommended to setup and activate a python virtual environment
5. Install the requirements `pip install --upgrade pip-requirements.txt`
### Running CI
1. clone your edk2 repo
2. Activate your python virtual environment in cmd window
3. Get code dependencies (done only when submodules change)
*`stuart_setup -c .pytool/CISettings.py TOOL_CHAIN_TAG=<your tag here>`
4. Update other dependencies (done more often)
*`stuart_update -c .pytool/CISettings.py TOOL_CHAIN_TAG=<your tag here>`
5. Run CI build (--help will give you options)
*`stuart_ci_build -c .pytool/CISettings.py TOOL_CHAIN_TAG=<your tag here>`
* -p <pkg1,pkg2,pkg3> : To build only certain packages use a CSV list
* -a <arch1,arch2,arch3>: To run only certain architectures use a CSV list
* -t <target1,target2>: To run only tests related to certain targets use a
CSV list
* By default all tests are opted in. Then given a package.ci.yaml file those
tests can be configured for a package. Finally setting the check to the
value `skip` will skip that plugin. Examples:
*`CompilerPlugin=skip` skip the build test
*`GuidCheck=skip` skip the Guid check
*`SpellCheck=skip` skip the spell checker
* etc
6. Detailed reports and logs per package are captured in the `Build` directory
## Current PyTool Test Capabilities
All CI tests are instances of EDKII Tools plugins. Documentation on the plugin
system can be found [here](https://github.com/tianocore/edk2-pytool-extensions/blob/master/docs/usability/using_plugin_manager.md)
and [here](https://github.com/tianocore/edk2-pytool-extensions/blob/master/docs/features/feature_plugin_manager.md).
Upon invocation, each plugin will be passed the path to the current package
under test and a dictionary containing its targeted configuration, as assembled
from the command line, per-package configuration, and global configuration.
Note: CI plugins are considered unique from build plugins and helper plugins,
even though some CI plugins may execute steps of a build.
In the example, these plugins live alongside the code under test (in the
`.pytool/Plugin` directory), but may be moved to the 'edk2-test' repo if that
location makes more sense for the community.
### Module Inclusion Test - DscCompleteCheck
This test scans all available modules (via INF files) and compares them to the
package-level DSC file for the package each module is contained within. The test
considers it an error if any module does not appear in the `Components` section
of at least one package-level DSC (indicating that it would not be built if the
package were built).
### Code Compilation Test - CompilerPlugin
Once the Module Inclusion Test has verified that all modules would be built if
all package-level DSCs were built, the Code Compilation Test simply runs through
and builds every package-level DSC on every toolchain and for every architecture
that is supported. Any module that fails to build is considered an error.
### GUID Uniqueness Test - GuidCheck
This test works on the collection of all packages rather than an individual
package. It looks at all FILE_GUIDs and GUIDs declared in DEC files and ensures
that they are unique for the codebase. This prevents, for example, accidental
duplication of GUIDs when using an existing INF as a template for a new module.
### Cross-Package Dependency Test - DependencyCheck
This test compares the list of all packages used in INFs files for a given
package against a list of "allowed dependencies" in plugin configuration for
that package. Any module that depends on a disallowed package will cause a test
failure.
### Library Declaration Test - LibraryClassCheck
This test scans at all library header files found in the `Library` folders in
all of the package's declared include directories and ensures that all files
have a matching LibraryClass declaration in the DEC file for the package. Any
missing declarations will cause a failure.
### Invalid Character Test - CharEncodingCheck
This test scans all files in a package to make sure that there are no invalid
Unicode characters that may cause build errors in some character
sets/localizations.
### Spell Checking - cspell
This test runs a spell checker on all files within the package. This is done
using the NodeJs cspell tool. For details check `.pytool/Plugin/SpellCheck`.
For this plugin to run during ci you must install nodejs and cspell and have
both available to the command line when running your CI.
Install
* Install nodejs from https://nodejs.org/en/
* Install cspell
1. Open cmd prompt with access to node and npm
2. Run `npm install -g cspell`
More cspell info: https://github.com/streetsidesoftware/cspell
## PyTool Scopes
Scopes are how the PyTool ext_dep, path_env, and plugins are activated. Meaning
that if an invocable process has a scope active then those ext_dep and path_env
will be active. To allow easy integration of PyTools capabilities there are a
few standard scopes.
| Scope | Invocable | Description |
| :---- | :----- | :---- |
| global | edk2_invocable++ - should be base_abstract_invocable | Running an invocables |
| global-win | edk2_invocable++ | Running on Microsoft Windows |
| global-nix | edk2_invocable++ | Running on Linux based OS |
| edk2-build | | This indicates that an invocable is building EDK2 based UEFI code |
| cibuild | set in .pytool/CISettings.py | Suggested target for edk2 continuous integration builds. Tools used for CiBuilds can use this scope. Example: asl compiler |
## Future investments
* PatchCheck tests as plugins
* MacOS/xcode support
* Clang/LLVM support
* Visual Studio AARCH64 and ARM support
* BaseTools C tools CI/PR and binary release process
DEBUG((EFI_D_LOAD|EFI_D_INFO,"Loading driver at 0x%11p EntryPoint=0x%11p\n",(VOID*)(UINTN)ImageContext->ImageAddress,FUNCTION_ENTRY_POINT(ImageContext->EntryPoint)));
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
