Ard Biesheuvel [Fri, 7 Dec 2018 10:57:22 +0000 (11:57 +0100)]
ArmPkg/ArmMmuLib: take MAX_ALLOC_ADDRESS into account
When creating the page tables for the 1:1 mapping, ensure that we don't
attempt to map more than what is architecturally permitted when running
with 4 KB pages, which is 48 bits of VA. This will be reflected in the
value of MAX_ALLOC_ADDRESS once we override it for AArch64, so use that
macro instead of MAX_ADDRESS.
Ard Biesheuvel [Fri, 7 Dec 2018 10:55:19 +0000 (11:55 +0100)]
MdeModulePkg/Dxe/Page: take MAX_ALLOC_ADDRESS into account
Take MAX_ALLOC_ADDRESS into account in the implementation of the
page allocation routines, so that they will only return memory
that is addressable by the CPU at boot time, even if more memory
is available in the GCD memory map.
Update the GCD memory map initialization code so it disregards
memory that is not addressable by the CPU at boot time. This
only affects the first memory descriptor that is added, other
memory descriptors are permitted that describe memory ranges
that may be accessible to the CPU itself only when executing
under the OS.
Ard Biesheuvel [Fri, 7 Dec 2018 10:27:32 +0000 (11:27 +0100)]
MdePkg/Base: introduce MAX_ALLOC_ADDRESS
On some architectures, the maximum representable address deviates from
the virtual address range that is accessible by the firmware at boot
time. For instance, on AArch64, UEFI mandates a 4 KB page size, which
limits the address space to 48 bits, while more than that may be
populated on a particular platform, for use by the OS.
So introduce a new macro MAX_ALLOC_ADDRESS, which represent the maximum
address the firmware should take into account when allocating memory
ranges that need to be accessible by the CPU at boot time.
Ard Biesheuvel [Tue, 11 Dec 2018 13:23:28 +0000 (14:23 +0100)]
ArmPkg/DefaultExceptionHandlerLib ARM: avoid endless loop in RELEASE builds
Ensure that we prevent the CPU from proceeding after having taken an
unhandled exception on a RELEASE build, which does not contain the
ASSERT() which ensures this on DEBUG and NOOPT builds.
Retain the code following the deadloop so that we can keep going when
running in a debugger.
Ard Biesheuvel [Wed, 12 Dec 2018 12:11:04 +0000 (13:11 +0100)]
BaseTools/tools_def ARM: emit PIC veneers
The ARM linker may emit veneers, i.e., trampolines, when ordinary
direct relative branches cannot be used, e.g., for Thumb interworking
or branch targets that are out of range.
Usually, such veneers carry an absolute reference to the branch
target, which is problematic for us, since these absolute references
are not covered by annotations that are visible to GenFw in the
PE/COFF conversion, and so these absolute references are not fixed
up by the PE/COFF loader at runtime.
So switch to all ARM GNU ld toolchains to position independent veneers.
Leif Lindholm [Tue, 18 Dec 2018 18:25:49 +0000 (18:25 +0000)]
ArmPkg: drop ArmBds remnant Pcds from .dec
The following Pcds
- gArmTokenSpaceGuid.PcdArmLinuxSpinTable
- gArmTokenSpaceGuid.PcdArmLinuxAtagMaxOffset
- gArmTokenSpaceGuid.PcdArmLinuxFdtMaxOffset
- gArmTokenSpaceGuid.PcdArmLinuxFdtAlignment
remained defined, without actual users.
So get rid of them.
One reference to be deleted separately from edk2-platforms.
The codes have been updated to not use PcdPeiCoreMaxFvSupported,
PcdPeiCoreMaxPeimPerFv and PcdPeiCoreMaxPpiSupported, so their
statement in platform DSC could be removed.
Cc: Zailiang Sun <zailiang.sun@intel.com> Cc: Yi Qian <yi.qian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Zailiang Sun <zailiang.sun@intel.com> Reviewed-by: Yi Qian <yi.qian@intel.com>
The codes have been updated to not use PcdPeiCoreMaxFvSupported,
PcdPeiCoreMaxPeimPerFv and PcdPeiCoreMaxPpiSupported, so their
statement in platform DSC could be removed.
Problem:
As static configuration from the PCDs, the binary PeiCore (for example
in FSP binary with dispatch mode) could not predict how many FVs,
Files or PPIs for different platforms.
Burden:
Platform developers need configure the PCDs accordingly for different
platforms.
To solve the problem and remove the burden, we can update code to
remove the using of PcdPeiCoreMaxFvSupported, PcdPeiCoreMaxPeimPerFv
and PcdPeiCoreMaxPpiSupported by extending buffer dynamically for FV,
File and PPI management.
This patch removes the using of PcdPeiCoreMaxPpiSupported in PeiCore.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Chasel Chiu <chasel.chiu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Problem:
As static configuration from the PCDs, the binary PeiCore (for example
in FSP binary with dispatch mode) could not predict how many FVs,
Files or PPIs for different platforms.
Burden:
Platform developers need configure the PCDs accordingly for different
platforms.
To solve the problem and remove the burden, we can update PeiCore to
remove the using of PcdPeiCoreMaxFvSupported, PcdPeiCoreMaxPeimPerFv
and PcdPeiCoreMaxPpiSupported by extending buffer dynamically for FV,
File and PPI management.
This patch removes the using of PcdPeiCoreMaxFvSupported in PeiCore.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Chasel Chiu <chasel.chiu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Problem:
As static configuration from the PCDs, the binary PeiCore (for example
in FSP binary with dispatch mode) could not predict how many FVs,
Files or PPIs for different platforms.
Burden:
Platform developers need configure the PCDs accordingly for different
platforms.
To solve the problem and remove the burden, we can update PeiCore to
remove the using of PcdPeiCoreMaxFvSupported, PcdPeiCoreMaxPeimPerFv
and PcdPeiCoreMaxPpiSupported by extending buffer dynamically for FV,
File and PPI management.
This patch removes the using of PcdPeiCoreMaxFvSupported in Tcg(2)Pei.
Problem:
As static configuration from the PCDs, the binary PeiCore (for example
in FSP binary with dispatch mode) could not predict how many FVs,
Files or PPIs for different platforms.
Burden:
Platform developers need configure the PCDs accordingly for different
platforms.
To solve the problem and remove the burden, we can update code to
remove the using of PcdPeiCoreMaxFvSupported, PcdPeiCoreMaxPeimPerFv
and PcdPeiCoreMaxPpiSupported by extending buffer dynamically for FV,
File and PPI management.
This patch removes the using of PcdPeiCoreMaxPeimPerFv in PeiCore.
Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao Wu <hao.a.wu@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Nate DeSimone <nathaniel.l.desimone@intel.com> Cc: Chasel Chiu <chasel.chiu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Zhiju.Fan [Tue, 18 Dec 2018 16:13:12 +0000 (00:13 +0800)]
BaseTools: Add $(INC)-like support when compiling .nasm files
current edk2\BaseTools\Conf\build_rule.template, the compile of nasm
source files does not have the $(INC) support.
The '-I' option only includes the directory of the nasm source file
(${s_path}(+)). Hence, it will be impossible for nasm files to include
files outside of the nasm source file directory.
As a comparison, the compile of both .s and .asm have $(INC) support
in their compile commands.
Feng, Bob C [Thu, 13 Dec 2018 08:16:25 +0000 (16:16 +0800)]
BaseTools: Fixed metafile parser issues
https://bugzilla.tianocore.org/show_bug.cgi?id=1406
This patch is going to fix the regressions that
is introduced by commit 2f818ed0fb57d98985d151781a2ce9b8683129ee
The internal array for storing the metadata info should be cached
so that the meta file is parsed only once in one build.
1. support hex number for array index
2. support Non-Dynamic Pcd for array data type
3. support {} and {CODE()} for array data type
4. Change GetStructurePcdMaxSize to be a static function since it need to
be called in another static function. And this function does not depend on
it's class instance.
5. Add unittest for RemoveCComments function and
ArrayIndex regular expression.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Bob Feng <bob.c.feng@intel.com> Cc: Liming Gao <liming.gao@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Philippe Mathieu-Daud? <philmd@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Fu Siyuan [Mon, 17 Dec 2018 01:29:39 +0000 (09:29 +0800)]
ArmVirtPkg: Remove redundant library instances in ArmVirtQemuKernel.dsc
Commit 9a67ba261fe9 ("ArmVirtPkg: Replace obsoleted network drivers
from platform DSC/FDF") incorrectly added the BaseCryptLib, OpensslLib
and IntrinsicLib to "ArmVirtPkg/ArmVirtQemuKernel.dsc", it's redundant
and the library instances from "ArmVirt.dsc.inc" is already sufficient.
This patch also adjust the order of network drivers in "ArmVirtPkg/
ArmVirtQemuFvMain.fdf.inc" to make it same as the DSC file.
When there is no PCI option ROM exists, today's logic still creates
virtual BAR for option ROM using Length = 0, Alignment = (-1).
It causes the final MEM32 alignment requirement is as big as
0xFFFFFFFF_FFFFFFFF.
The patch fixes this issue by only creating virtual BAR for option
ROM when there is PCI option ROM.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Chiu Chasel <chasel.chiu@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Cc: Jian J Wang <jian.j.wang@intel.com> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
UEFI SCT crashed and failed in NonDiscoverablePciDeviceDxe becase
required checks were not performed. Perform parameters validation in
NonDiscoverablePciDeviceDxe.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Our default is already armv7-a, so no need to rewrite the PLATFORM_FLAGS
for that. Also, setting -mfpu=neon is not entirely inappropriate, since
NEON is not mandatory under v7.
Feng, Bob C [Sun, 9 Dec 2018 13:44:32 +0000 (21:44 +0800)]
BaseTools: Fixed the build fail issue for cases
https://bugzilla.tianocore.org/show_bug.cgi?id=1386
This patch is going to fix the regression issue that is
introduced by commit 72a1d77694d51914c0dd6aa97dbfa58634b0a4a5
The issue will happen in the following cases:
1. There is no Pcd value assignment in Dsc file
2. There are duplicate Pcd filed assignment
PcdNvStoreDefaultValueBuffer value is update to Vpd Info File,
but it is not update into a internal cache. This patch will
fix this incorrect value in that internal cache.
Commit 9a67ba261fe9 ("ArmVirtPkg: Replace obsoleted network drivers
from platform DSC/FDF") failed to take into account that the now
unconditionally included IScsiDxe.inf from NetworkPkg requires a
resolution for TcpIoLib. Since specifying such a resolution is harmless
for platforms that have no networking enabled, let's just fix things
by dropping the conditionals around it.
Fu Siyuan [Tue, 30 Oct 2018 06:53:39 +0000 (14:53 +0800)]
ArmVirtPkg: Replace obsoleted network drivers from platform DSC/FDF.
This patch replaces the MdeModulePkg TCP, PXE and iSCSI driver with those
ones in NetworkPkg. These 3 drivers in MdeModulePkg are not being actively
maintained and will be removed from edk2 master soon.
Ard Biesheuvel [Wed, 12 Dec 2018 10:10:20 +0000 (11:10 +0100)]
BaseTools/tools_def ARM CLANG35: work around -mno-movt option name change
PE/COFF only has a very limited id space for runtime relocations, and
so it defines only a single relocation for movw/movt instruction pairs,
which can be combined to load a 32-bit symbol reference into a register.
For this to work as expected, these instructions must always appear in
the same order and adjacently, and this is something few compilers take
into account, unless they target PE/COFF explicitly (and this is not the
case for our ELF based toolchains)
For Clang 3.6 and later, we can pass the -mno-movt option to suppress
movw/movt pairs entirely, which works around the issue. Unfortunately,
for Clang 3.5, the option is called differently (-mllvm -arm-use-movt=0)
and mutually incompatible between 3.5 and 3.6.
Since it is desirable for the CLANG35 toolchain to be usable on newer
versions of Clang as well (given that it is the only non-LTO alternative
to CLANG38), let's work around this issue in a way that permits versions
3.5 and newer of Clang to be used with the CLANG35 profile.
So pass the -mkernel flag instead (and add -Qunused-argument so Clang
does not complain about the -mno-unaligned-access in ARM_CC_XIPFLAGS).
This also inhibits movw/movt generation, along with some other changes
(e.g., long calls) which do affect code generation but not in an
undesirable manner.
Ard Biesheuvel [Wed, 12 Dec 2018 10:04:44 +0000 (11:04 +0100)]
MdePkg/BaseMemoryLibOptDxe ARM: add missing function annotations
ARM uses the low order bit of a branch target address to decide in
which execution mode (ARM or Thumb) a function needs to be called.
In order for this to work across object files, ELF function symbols
will have the low bit set if they were emitted in Thumb mode and
cleared otherwise. This annotation is only emitted if the ELF symbols
are annotated as function, since taking the address of some data
symbol (e.g., a literal) should not produce a value with the low bit
set, even if it appears in an object file containing Thumb code.
This means that all functions coded in assembler must have this
function annotation, or they may end up getting called in the
wrong mode, crashing the program.
We currently permit R_ARM_GOT_PREL relocations in the ELF32 conversion
routines, under the assumption that relative relocations are fine as
long as the section layout is the same between ELF and PE/COFF.
However, as is the case with any proxy generating relocation, it is
up to the linker to emit an entry in the GOT table and populate it
with the correct absolute address, which should also be fixed up at
PE/COFF load time. Unfortunately, the relocations covering the GOT
section are not emitted into the static relocation sections processed
by GenFw, but only in the dynamic relocation section as a R_ARM_RELATIVE
relocation, and so GenFw fails to emit the correct PE/COFF relocation
data for GOT entries.
Since GOT indirection is pointless anyway for PE/COFF modules running
in UEFI context, let's just drop the references to R_ARM_GOT_PREL from
GenFw, resulting in a build time failure rather than a runtime failure
if such relocations do occur.
Ard Biesheuvel [Tue, 11 Dec 2018 12:01:10 +0000 (13:01 +0100)]
ArmVirtPkg/PrePiUniCoreRelocatable CLANG38: work around build issues
The self-relocating PrePi module that is used by the ArmVirtQemuKernel
and ArmVirtXen targets runs the linker in PIE mode so that it emits
dynamic relocations into the final image in a way that permits the
module to relocate itself into place before calling into the C code.
When building these targets using the CLANG38 toolchain, we switch
from the BFD to the GOLD linker, which behaves a bit differently when
building PIE executables, and insists on emitting GOT indirected symbol
references throughout, which means a) that we end up with absolute
addresses (which need to be fixed up at load time) for no good reason,
and b) we have to add support for handling GOT entries to GenFw if we
want to convert them into PE/COFF.
So instead, let's emit a shared library. Since the ELF image only serves
as the input to GenFw, this does not lead to any loss of functionality,
although it does require the -Bsymbolic linker option to be added to
ensure that no symbol based dynamic relocations are emitted (which
would, e.g., permit lazy binding for shared libraries). So for all
other toolchains, the linker option changes are a no-op.
Then, we have to convince CLANG38/GOLD that there is no need to refer
to symbols via a GOT entry. This is done by forcing hidden visibility
for all symbols in all components that make up the PrePi SEC module:
this informs the linker that a symbol is never exported or preempted,
making it safe to refer to it directly from anywhere in the code,
rather than indirectly via a GOT entry.
Ard Biesheuvel [Tue, 11 Dec 2018 09:21:25 +0000 (10:21 +0100)]
ArmVirtPkg/ArmVirtQemuKernel ARM: make some PCD settings apply to ARM
Move some PCD settings outs of the [PcdsFixedAtBuild.AARCH64] block,
so that they apply to 32-bit ARM as well. Without this change, the
ARM build doesn't work.
Ard Biesheuvel [Mon, 10 Dec 2018 14:13:39 +0000 (15:13 +0100)]
BaseTools/tools_def AARCH64 RELEASE: move GCC49/GGC5 to 4 KB alignment
Since 4 KB section alignment is required when mapping PE/COFF images
with strict permissions, update the default section alignment when
using GCC49 and GCC5 in RELEASE mode. Note that XIP modules such as
SEC, PEIMs or PEI core are not affected by this change, since the
override to 32 byte aligment remains in effect.
Ard Biesheuvel [Sat, 8 Dec 2018 10:24:31 +0000 (11:24 +0100)]
MdeModulePkg/FileExplorerLib: avoid packed struct for program data
Struct packing is only necessary for data structures whose in-memory
representation is covered by the PI or UEFI specs, and may deviate
from the ordinary C rules for alignment.
So in case of FileExplorerLib, this applies to the device path struct
only, and other structures used to carry program data should not be
packed, or we may end up with alignment faults on architectures such
as ARM, which don't permit load/store double or multiple instructions
to access memory locations that are not 32-bit aligned.
E.g., the following call in FileExplorerLibConstructor()
will perform a double-word store on the first argument, passed in
register r0, assuming that the pointer type of the argument is
enough to guarantee that the value is suitably aligned.
Eric Dong [Mon, 10 Dec 2018 07:32:14 +0000 (15:32 +0800)]
UefiCpuPkg/Cpuid.h: Sync CPUID definition to latest SDM.
Update CPUID definition to follow SDM 2018'11 version, changes Include:
1. Add new fields to the existed data structure, impact CPUIDs include:
1. CPUID_THERMAL_POWER_MANAGEMENT 0x06
CPUID_THERMAL_POWER_MANAGEMENT_EAX
2. CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS 0x07
CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS_EBX
CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS_ECX
3. CPUID_ARCHITECTURAL_PERFORMANCE_MONITORING 0x0A
CPUID_ARCHITECTURAL_PERFORMANCE_MONITORING_EDX
4. CPUID_EXTENDED_STATE 0x0D
CPUID_EXTENDED_STATE_MAIN_LEAF_EAX
CPUID_EXTENDED_STATE_SUB_LEAF_ECX
5. CPUID_INTEL_RDT_ALLOCATION 0x10
CPUID_INTEL_RDT_ALLOCATION_ENUMERATION_SUB_LEAF_EBX
6. CPUID_INTEL_SGX 0x12
CPUID_INTEL_SGX_CAPABILITIES_0_SUB_LEAF_EAX
2. Add new data structures which not existed before, impact CPUID includes:
1. CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS 0x07
CPUID_STRUCTURED_EXTENDED_FEATURE_FLAGS_EDX
3. Remove fields which defined before, impact CPUID includes:
1. CPUID_INTEL_RDT_ALLOCATION 0x10
CPUID_INTEL_RDT_ALLOCATION_L3_CACHE_SUB_LEAF 0x01
CPUID_INTEL_RDT_ALLOCATION_L3_CACHE_SUB_LEAF_ECX
4. Add new sub leaf which not existed before, impact CPUID includes:
1. CPUID_INTEL_RDT_ALLOCATION 0x10
CPUID_INTEL_RDT_ALLOCATION_MEMORY_BANDWIDTH_SUB_LEAF 0x03
5. Add new CPUIDs which not exist before, new CPUIDs include:
1. CPUID_DETERMINISTIC_ADDRESS_TRANSLATION_PARAMETERS 0x18
2. CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION 0x1F
Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
BaseLib interfaces are used in this library but not declared in module's
inf file. This patch fix this situation to keep inf and its code in
consistency. No functionality or interface change are involved.
Cc: Qin Long <qin.long@intel.com> Cc: Ting Ye <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
Today's implementation reuses the 32bit MMIO resource requested by
all PCI devices MMIO BARs when shadowing the option ROM.
Take a simple example, a system has only one PCI device. It requires
8MB 32bit MMIO and contains a 4MB option ROM. Today's implementation
only requests 8MB (max of 4M and 8M) 32bit MMIO from
PciHostBridgeResourceAllocation protocol. Let's assume the MMIO range
[3GB, 3GB+8MB) is allocated. The 3GB base address is firstly
programmed to the option ROM BAR for option ROM shadow. Then the
option ROM decoding is turned off and 3GB base address is programmed
to the 32bit MMIO BAR.
It doesn't cause issues when the device doesn't request too much
MMIO.
But when the device contains a 64bit MMIO BAR which requests 4GB MMIO
and a 4MB option ROM. Let's assume [3GB, 3GB+8MB) 32bit MMIO range is
allocated for the option ROM. When the option ROM is being shadowed,
64bit MMIO BAR is programmed to value 0, which means [0, 4GB) MMIO is
given to the 64bit BAR.
The range overlaps with the option ROM range which may cause the
device malfunction (e.g.: option ROM cannot be read out) when the
device has two separate decoders: one for MMIO BAR, the other for
option ROM.
The patch requests dedicated MEM32 resource for Option ROMs and
moves the Option ROM shadow logic after all MMIO BARs are programmed.
The MMIO BAR setting to 0 when shadowing Option ROM is also skipped
because the MMIO BAR already contains the correct value.
Sughosh Ganu [Mon, 3 Dec 2018 07:19:02 +0000 (12:49 +0530)]
StandaloneMM: Update permissions for Standalone MM drivers memory area
The StandaloneMM image executes in S-EL0 on reference Arm platforms
and is deployed by the trusted firmware as BL32 image. Memory for the
Standalone MM drivers is marked as RW+XN initially, allowing the
drivers to be loaded into the memory. Once loaded, the memory
attributes need to be changed to RO+XN for rodata sections and RO+X
for code sections.
Achieve this through the extra action 'UpdatePeCoffPermissions' to
request the privileged firmware in EL3 to update the permissions.
Sughosh Ganu [Mon, 3 Dec 2018 07:19:01 +0000 (12:49 +0530)]
StandaloneMM: Include the newly added library class for MMU functions
The MMU functions needed for StandaloneMM image are now exported
through a separate library class. Make the corresponding change in the
core's entry point inf file so that it references the correct library
class for modifying the MMU attributes.
Achin Gupta [Mon, 3 Dec 2018 07:20:54 +0000 (12:50 +0530)]
StandaloneMmPkg: Zero data structure explicitly
Introduction of the -mstrict-align flag results in GCC attempting
to use memset to zero out the InitMmFoundationSvcArgs structure.
In the absence of this C library function, this patch explicitly
zeroes this data structure prior to use.
Achin Gupta [Mon, 3 Dec 2018 07:20:53 +0000 (12:50 +0530)]
StandaloneMmPkg: Enforce alignment check for AArch64
On AArch64, Standalone MM during the SEC phase runs in S-EL0 with
SCTLR_EL1.A=1. This patch adds the -mstrict-align compiler flag to
ensure that the generated code is compliant with the runtime
alignment checks.
On AArch64, we can only use 48 address bits while running in UEFI,
while the GCD and UEFI memory maps may describe up to 52 bits of
physical address space. For this reason, MAX_ADDRESS was reduced
to 48 bits, to ensure that the firmware does not inadvertently
attempt to allocate memory that we cannot access.
However, MAX_ADDRESS is used in runtime drivers as well, and
runtime drivers may deal with kernel virtual addresses, which have
bits [63:48] set. In fact, the OS may be running with 64 KB pages
and pass addresses into the runtime services that use up to 52
bits of address space, either with the top bits set or cleared,
even if the physical address space does not extend beyond 48 bits.
In summary, changing MAX_ADDRESS is a mistake, and needs to be
reverted.
This patch is one of build tool performance improvement
series patches.
This patch is going to use join function instead of
string += string2 statement.
Current code use string += string2 in a loop to combine
a string. while creating a string list in a loop and using
"".join(stringlist) after the loop will be much faster.
[V2]
Optimize this patch so that it can be easy to review.
This patch is just apply the change to original files while
not create new similar files.
[V1]
This patch is one of build tool performance improvement
series patches.
This patch is going to use python list to store the parser data
instead of using sqlite database.
The replacement solution is as below:
SQL insert: list.append()
SQL select: list comprehension. for example:
Select * from table where field = “something”
->
[ item for item in table if item[3] == “something”]
SQL update: python map function. for example:
Update table set field1=newvalue where filed2 = “something”.
-> map(lambda x: x[1] = newvalue,
[item for item in table if item[2] == “something”])
SQL delete: list comprehension.
With this change, We can save the time of interpreting SQL statement
and the time of write database to file system
Currently, AutoGen and GenFds run in different python interpreters. The
parser are duplicated. This patch is going to create new API for GenFds
and have the build to call that API instead of executing GenFds.py. As
such, the GenFds and build can share the parser data.
This patch is expected to save the time of GenFds about 2~3 seconds.
More details will be logged in BZ.
This is the summary measure data generated from python cProfile for
building Ovmf.
Currently: 8379147 function calls (8135450 primitive calls) in 12.580 seconds
After applying this patch: 3428712 function calls (3418881 primitive calls) in 8.944 seconds
Feng, Bob C [Thu, 1 Nov 2018 14:57:08 +0000 (22:57 +0800)]
BaseTool: Filter out unused structure pcds
V2:
Fixed the issue that V1 adds new check
to the Pcds in the platform unused library INF files.
It breaks the existing platform.
V1?
The current code handle all the structure pcds
even if there is no module or library use them.
This patch is going to filter out the unused structure pcds.
Ard Biesheuvel [Wed, 5 Dec 2018 08:15:48 +0000 (09:15 +0100)]
BaseTools/CommonLib: drop the use of MAX_ADDRESS
The macro MAX_ADDRESS represents the largest virtual address that
is valid for a certain architecture. For the BaseTools, this quantity
is irrelevant, since the same tools can be used to build for different
targets.
Since we only refer to it in a single place, which is an ASSERT() that
doesn't seem particularly useful (it ensures that memcpy() will not
be called with arguments that will make it read beyond the end of the
address space and wrap around), let's drop the ASSERT and all references
to MAX_ADDRESS.
Shenglei Zhang [Fri, 30 Nov 2018 02:30:05 +0000 (10:30 +0800)]
BaseTools: Remove tools only used by DuetPkg
Given that DuetPkg will be removed, tools only used by
DuetPkg can also be removed after its removal operation.
https://bugzilla.tianocore.org/show_bug.cgi?id=1322
v2:Remove these tools in Makefile and GNUmakefile.
v4:Remove these tools in BinWrappers/PosixLike/ and
UserManuals.
Shenglei Zhang [Fri, 30 Nov 2018 02:30:38 +0000 (10:30 +0800)]
DuetPkg: Remove DuetPkg
DuetPkg depends on Legacy BIOS to provide a UEFI environment.
It was invented in the era when UEFI environment is hard to find.
Since now UEFI is very popular in PC area, we could stop the
official support of this package and remove it from the master.
https://bugzilla.tianocore.org/show_bug.cgi?id=1322
Ard Biesheuvel [Thu, 29 Nov 2018 12:22:46 +0000 (13:22 +0100)]
BaseTools/CommonLib: drop definition of MAX_UINTN
The maximum value that can be represented by the native word size
of the *target* should be irrelevant when compiling tools that
run on the build *host*. So drop the definition of MAX_UINTN, now
that we no longer use it.
Ard Biesheuvel [Thu, 29 Nov 2018 12:05:38 +0000 (13:05 +0100)]
BaseTools/CommonLib: get rid of 'native' type string parsing routines
Parsing a string into an integer variable of the native word size
is not defined for the BaseTools, since the same tools may be used
to build firmware for different targets with different native word
sizes.
Ard Biesheuvel [Wed, 5 Dec 2018 07:56:58 +0000 (08:56 +0100)]
BaseTools/CommonLib: add definition of MAX_UINT32
Since we will be dropping the definition of MAX_UINTN, whose meaning
is ambiguous for the BaseTools, add a definition of MAX_UINT32 that
we can switch to.
Ard Biesheuvel [Thu, 29 Nov 2018 12:13:32 +0000 (13:13 +0100)]
BaseTools/CommonLib: use explicit 64-bit type in Strtoi()
Don't use the native word size string to number parsing routines,
but instead, use the 64-bit one and cast to UINTN.
Currently, the only user is in Source/C/DevicePath/DevicePathFromText.c
which takes care to use Strtoi64 () unless it assumes the value fits
in 32-bit, so this change is a no-op even on 32-bit build hosts.
Ard Biesheuvel [Thu, 29 Nov 2018 12:00:20 +0000 (13:00 +0100)]
BaseTools/CommonLib: avoid using 'native' word size in IP address handling
In the context of the BaseTools, there is no such thing as a native word
size, given that the same set of tools may be used to build a firmware
image consisting of both 32-bit and 64-bit modules.
So update StrToIpv4Address() and StrToIpv6Address() to use UINT64
types instead of UINTN types when parsing strings.
Shenglei Zhang [Fri, 23 Nov 2018 05:43:41 +0000 (13:43 +0800)]
BaseTools: Remove GenVtf
GenVtf C tool is IPF specific. IPF support has been removed
from edk2 trunk. This tool can be removed.
https://bugzilla.tianocore.org/show_bug.cgi?id=1349
v2:Remove GenVtf in Makefile and GNUmakefile.
v3:Remove BinWrappers/PosixLike/GenVtf and the user manual
of GenVtf.
Ard Biesheuvel [Fri, 30 Nov 2018 11:28:29 +0000 (12:28 +0100)]
ArmVirtPkg/QemuVirtMemInfoLib: trim the MMIO region mapping
QEMU/mach-virt is rather unhelpful when it comes to tracking down
NULL pointer dereferences that occur while running in UEFI: since
we have NOR flash mapped at address 0x0, inadvertent reads go
unnoticed, and even most writes are silently dropped, unless you're
unlucky and the instruction in question is one that KVM cannot
emulate, in which case you end up with a QEMU crash like this:
and a warning in the host kernel log that load/store instruction
decoding is not supported by KVM.
Given that the first page of the flash device is not actually
used anyway, let's reduce the mappings of the peripheral space
and the flash device (both of which cover page #0) to only cover
what is actually required:
For ArmVirtQemu, the resulting virtual mapping looks roughly like:
- [0, 4K) : flash, unmapped
- [4K, 2M) : flash, mapped as WB+X RAM
- [2M, 64M) : flash, unmapped
- [64M, 128M) : varstore flash, will be mapped by the NOR flash driver
- [128M, 256M) : peripherals, mapped as device
- [256M, 1GB) : 32-bit MMIO aperture, translated IO aperture, ECAM,
will be mapped by the PCI host bridge driver
- [1GB, ...) : RAM, mapped.
After this change, any inadvertent read or write from/to the first
physical page will trigger a translation fault inside the guest,
regardless of the nature of the instruction, without crashing QEMU.
The primary FV contains the firmware boot image, which is not
runtime updatable in our case. So exposing it to the NOR flash
driver is undesirable, since it may attempt to modify the NOR
flash contents. It is also rather pointless, since we don't
keep anything there that we care to expose. (the SEC and PEI
phase modules are not executable from DXE context, and the
contents of the embedded DXE phase FV are exposed by the DXE
core directly via the FVB2 protocol)
So let's disregard the NOR flash block that covers the primary
FV.
Ard Biesheuvel [Fri, 30 Nov 2018 11:28:27 +0000 (12:28 +0100)]
ArmPkg/ArmMmuLib ARM: handle unmapped sections when updating permissions
The ARM ArmMmuLib code currently does not take into account that
setting permissions on a region should take into account that a
region may not be mapped yet to begin with.
So when updating a section descriptor whose old value is zero,
pass in the address explicitly.
Ard Biesheuvel [Fri, 30 Nov 2018 11:28:26 +0000 (12:28 +0100)]
ArmPkg/ArmMmuLib ARM: handle unmapped section in GetMemoryRegion()
GetMemoryRegion() is used to obtain the attributes of an existing
mapping, to permit permission attribute changes to be optimized
away if the attributes don't actually change.
The current ARM code assumes that a section mapping or a page mapping
exists for any region passed into GetMemoryRegion(), but the region
may be unmapped entirely, in which case the code will crash. So check
if a section mapping exists before dereferencing it.
Liming Gao [Thu, 29 Nov 2018 00:55:56 +0000 (08:55 +0800)]
MdeModulePkg: Correct PCD name in MdeModulePkg.uni
https://bugzilla.tianocore.org/show_bug.cgi?id=1363
New PCD PcdVpdBaseAddress64 is added in MdeModulePkg.dec.
Its string token in MdeModulePkg.uni should match to its name.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Bi Dandan <dandan.bi@intel.com> Cc: Star Zeng <star.zeng@intel.com> Reviewed-by: Bi Dandan <dandan.bi@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Ard Biesheuvel [Mon, 26 Nov 2018 21:36:33 +0000 (22:36 +0100)]
BeagleBoardPkg/PrePi: base GCD memory space size on CPU's PA range
Derive the size of the GCD memory space map directly from the CPU's
information registers rather than from the PcdPrePiCpuMemorySize PCD,
which will be removed.
Ard Biesheuvel [Mon, 26 Nov 2018 21:35:02 +0000 (22:35 +0100)]
ArmVirtPkg/PrePi: base GCD memory space size on CPU's PA range
Derive the size of the GCD memory space map directly from the CPU's
information registers rather than from the PcdPrePiCpuMemorySize PCD,
which will be removed.
Ard Biesheuvel [Mon, 26 Nov 2018 21:34:05 +0000 (22:34 +0100)]
ArmPlatformPkg/PrePi: base GCD memory space size on CPU's PA range
Derive the size of the GCD memory space map directly from the CPU's
information registers rather than from the PcdPrePiCpuMemorySize PCD,
which will be removed.
Ard Biesheuvel [Mon, 26 Nov 2018 21:22:20 +0000 (22:22 +0100)]
ArmPkg/CpuPei: base GCD memory space size on CPU's PA range
Derive the size of the GCD memory space map directly from the CPU's
information registers rather than from the PcdPrePiCpuMemorySize PCD,
which will be removed.
Ard Biesheuvel [Fri, 23 Nov 2018 12:14:28 +0000 (13:14 +0100)]
ArmPkg/ArmMmuLib: take the CPU supported maximum PA space into account
In preparation of dropping PcdPrePiCpuMemorySize entirely, base the
maximum size of the identity map on the capabilities of the CPU.
Since that may exceed what is architecturally permitted when using
4 KB pages, take MAX_ADDRESS into account as well.
Ard Biesheuvel [Tue, 27 Nov 2018 12:23:35 +0000 (13:23 +0100)]
MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bits
AArch64 supports the use of more than 48 bits for physical and/or
virtual addressing, but only if the page size is set to 64 KB,
which is not supported by UEFI. So redefine MAX_ADDRESS to cover
only 48 address bits.
Ard Biesheuvel [Tue, 27 Nov 2018 14:25:42 +0000 (15:25 +0100)]
ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range
Currently, we map DRAM as EFI_MEMORY_WB, and the remainder of the
entire virtual address space is mapped with EFI_MEMORY_UC attributes,
regardless of whether any devices actually reside there.
Now that we are relaxing the address space limit to more than 40 bits,
mapping all that address space actually takes up more space in page
tables than we have so far made available as temporary RAM. So let's
get rid of the mapping rather than increasing the available RAM, given
that the mapping is not particularly useful anyway.
Ard Biesheuvel [Tue, 27 Nov 2018 14:18:38 +0000 (15:18 +0100)]
ArmVirtPkg/FdtPciHostBridgeLib: map ECAM and I/O spaces in GCD memory map
Up until now, we have been getting away with not declaring the ECAM
and translated I/O spaces at all in the GCD memory map, simply because
we map the entire address space with device attributes in the early PEI
code, and so the ECAM space will be mapped wherever it ends up.
Now that we are about to make changes to how ArmVirtQemu reasons
about the size of the address space, it would be better to get rid
of this mapping of the entire address space, since it can get
arbitrarily large without real benefit.
So start by mapping the ECAM and translated I/O spaces explicitly,
instead of relying on the early PEI mapping.
projects / mirror_edk2.git / log