Make BaseRngLib more generic by moving x86-specific functionality into
'Rand' and adding files under 'AArch64' to support the optional ARMv8.5
RNG instruction RNDR that is a part of FEAT_RNG.
Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3325
1. AsmReadMsr64() in X64/GccInlinePriv.c
AsmReadMsr64 can return uninitialized value if FilterBeforeMsrRead
returns False. This causes build error with the CLANG toolchain.
2. AsmWriteMsr64() in X64/GccInlinePriv.c
In the case that FilterBeforeMsrWrite changes Value and returns True,
The original Value, not the changed Value, is written to the MSR.
This behavior is different from the one of AsmWriteMsr64() in
X64/WriteMsr64.c for the MSFT toolchain.
Signed-off-by: Takuto Naito <naitaku@gmail.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
CpuPause() might allow the CPU to go into a lower power state
state while we spin.
On X86, CpuPause() executes a PAUSE instruction which the Intel
and AMD specs describe as follows:
Intel:
"PAUSE: An additional function of the PAUSE instruction is to reduce
the power consumed by a processor while executing a spin loop. A
processor can execute a spin-wait loop extremely quickly, causing the
processor to consume a lot of power while it waits for the resource it
is spinning on to become available. Inserting a pause instruction in a
spin-wait loop greatly reduces the processor?s power consumption."
AMD:
"PAUSE: Improves the performance of spin loops, by providing a hint to
the processor that the current code is in a spin loop. The processor
may use this to optimize power consumption while in the spin loop.
Architecturally, this instruction behaves like a NOP instruction."
On RISC-V and ARM64, CpuPause() executes a NOP, which is no worse than
the tight loop we have.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3168
This interface provides an abstration layer to allow MM modules to access
requested areas that are outside of MMRAM. On MM model that blocks all
non-MMRAM accesses, areas requested through this API will be mapped or
unblocked for accessibility inside MM environment.
For MM modules that need to access regions outside of MMRAMs, the agents
that set up these regions are responsible for invoking this API in order
for these memory areas to be accessible from inside MM.
Example usages:
1. To enable runtime cache feature for variable service, Variable MM
module will need to access the allocated runtime buffer. Thus the agent
sets up these buffers, VariableSmmRuntimeDxe, will need to invoke this
API to make these regions accessible by Variable MM.
2. For TPM ACPI table to communicate to physical presence handler, the
corresponding NVS region has to be accessible from inside MM. Once the
NVS region are assigned, it needs to be unblocked thourgh this API.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Kun Qin <kun.q@outlook.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Message-Id: <MWHPR06MB31028AF0D0785B93E4E7CF63F3969@MWHPR06MB3102.namprd06.prod.outlook.com>
The Raspberry Pi platform with Secure Boot enabled currently fails to build
with error:
Module type [DXE_RUNTIME_DRIVER] is not supported by library instance
[/home/appveyor/projects/rpi4/edk2/MdePkg/Library/DxeRngLib/DxeRngLib.inf]
Add the missing class to fix this issue.
Signed-off-by: Pete Batard <pete@akeo.ie>
Reviewed-by: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Reviewed-by: Andrei Warkentin <awarkentin@vmware.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The current SSE2 implementation of the ZeroMem(), SetMem(),
SetMem16(), SetMem32 and SetMem64 functions is writing 16 bytes per 16
bytes. It hurts the performances so bad that this is even slower than
a simple 'rep stos' (4% slower) in regular DRAM.
To take full advantages of the 'movntdq' instruction it is better to
"queue" a total of 64 bytes in the write combining buffers. This
patch implement such a change. Below is a table where I measured
(with 'rdtsc') the time to write an entire 100MB RAM buffer. These
functions operate almost two times faster.
| Function | Arch | Untouched | 64 bytes | Result |
|----------+------+-----------+----------+--------|
| ZeroMem | Ia32 | 17765947 | 9136062 | 1.945x |
| ZeroMem | X64 | 17525170 | 9233391 | 1.898x |
| SetMem | Ia32 | 17522291 | 9137272 | 1.918x |
| SetMem | X64 | 17949261 | 9176978 | 1.956x |
| SetMem16 | Ia32 | 18219673 | 9372062 | 1.944x |
| SetMem16 | X64 | 17523331 | 9275184 | 1.889x |
| SetMem32 | Ia32 | 18495036 | 9273053 | 1.994x |
| SetMem32 | X64 | 17368864 | 9285885 | 1.870x |
| SetMem64 | Ia32 | 18564473 | 9241362 | 2.009x |
| SetMem64 | X64 | 17506951 | 9280148 | 1.886x |
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Correct the memory offsets used in REG_ONE/REG_PAIR macros to
synchronize them with definition of the BASE_LIBRARY_JUMP_BUFFER
structure on AArch64.
The REG_ONE macro declares only a single 64-bit register be
read/written; however, the subsequent offset is 16 bytes larger,
creating an unused memory gap in the middle of the structure and
causing SetJump/LongJump functions to read/write 8 bytes of memory
past the end of the jump buffer struct.
Signed-off-by: Jan Bobek <jbobek@nvidia.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Liming Gao <gaoliming@byosoft.com.cn>
If the size of the supplied buffer in FileHandleReadLine(), module
UefiFileHandleLib.c, was not 0, but was not enough to fit in
the line, the size is increased, and then the Buffer of the new
size is zeroed. This size is always larger than the supplied buffer size,
causing supplied buffer overrun. Fix the issue by using the
supplied buffer size in ZeroMem().
Signed-off-by: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Message-Id: <20200702023113.10517-1-vladimir.olovyannikov@broadcom.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
[lersek@redhat.com: remove stray space character from subject line]
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
VMGEXIT is a new instruction used for Hypervisor/Guest communication when
running as an SEV-ES guest. A VMGEXIT will cause an automatic exit (AE)
to occur, resulting in a #VMEXIT with an exit code value of 0x403.
Since SEV-ES is only supported in X64, provide the necessary X64 support
to execute the VMGEXIT instruction, which is coded as "rep vmmcall". For
IA32, since "vmmcall" is not supported in NASM 32-bit mode and VMGEXIT
should never be called, provide a stub implementation that is identical
to CpuBreakpoint().
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
While RISC-V hart is trapped into S-Mode, the S-Mode interrupt
CSR (SIE) is disabled by RISC-V hart. However the (SIE) is enabled
again by RestoreTPL, this causes the second S-Mode trap is triggered
by the machine mode (M-Mode)timer interrupt redirection. The SRET
instruction clear Supervisor Previous Privilege (SPP) to zero
(User mode) in the second S-Mode interrupt according to the RISC-V
spec. Above brings hart to the user mode (U-Mode) when execute
SRET in the nested S-Mode interrupt handler because SPP is set to
User Mode in the second interrupt. Afterward, system runs in U-Mode
and any accesses to S-Mode CSR causes the invalid instruction exception.
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Daniel Schaefer <daniel.schaefer@hpe.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Signed-off-by: Abner Chang <abner.chang@hpe.com>
Acked-by: Liming Gao <liming.gao@intel.com>
Update INF file to use a [Pcd] section instead of a
[FixedPcd] section. [FixedPcd] should only be used in an
INF file if the source code looks up the PCD value using
the PcdLib FixedPcdGetxx() services. Using [FixedPcd]
forces a platform to configure the PCD to type FixedAtBuild.
In this case, PcdDebugPropertyMask supports PCD types
FixedAtBuild and PatchableInModule. Without this change
any platform that wants to use PcdDebugPropertyMask as
type PatchableInModule breaks the build.
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>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2800
Add a new version of BaseLib that is safe for use from host based
unit test applications. Host based unit test applications may need
to provide implementations of some BaseLib functions that provide
simple emulation to exercise the code under test. The structure
UNIT_TEST_HOST_BASE_LIB is filled in with services that provide
default emulation for BaseLib APIs that would normally generate
exceptions in a host based unit test application. This structure
allows an individual unit test to replace the default emulation of
a BaseLib service with an alternate version that is required by a
specific unit test. A global variable of type UNIT_TEST_HOST_BASE_LIB
is provided through the new UnitTestHostBaseLib library class.
Normally cmocka would be used to mock services the code under
test calls. However, the BaseLib is used by the Unit Test
Framework itself, so using a mocked interface is not possible.
The use of a structure to provide hooks for unit test is not
expected to be a common feature. It should only be required
for libraries that are used by both the Unit Test Framework and
the code under test where the code under test requires a
different behavior than the Unit Test Framework.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
All public APIs should have EFIAPI modifier. Somehow PciSegmentInfoLib
missed the EFIAPI modifier.
The patch updates the library header file and NULL instance in MdePkg
to add the missing EFIAPI.
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>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
The mStatusString[] array is constructed as an array of pointer-to-char,
which means that on X64 or AARCH64, it is emitted as a single linear list
of 64-bit quantities, each containing the absolute address of one of the
string literals in memory.
This means that each string takes up 8 bytes of additional space, along
with 2 bytes of relocation data. It also means that extra work needs to
be done at runtime to process these relocations, every time a module is
loaded that incorporates this library.
So fix both issues, by splitting mStatusString into two arrays of char
arrays. The memory footprint decreases from 955 to 843 bytes, and given
that in the latter case, the overhead consists of 278 NUL characters rather
than 390 bytes worth of absolute addresses and relocation records, the size
of a compressed image is reduced even further. For example, when building
ArmVirtQemu.dsc in RELEASE mode for AARCH64 with the GCC5 profile, I get:
Before
FV Space Information
FVMAIN [100%Full] 5329920 total, 5329920 used, 0 free
FVMAIN_COMPACT [38%Full] 2093056 total, 811840 used, 1281216 free
After
FV Space Information
FVMAIN [100%Full] 5321728 total, 5321728 used, 0 free
FVMAIN_COMPACT [38%Full] 2093056 total, 809696 used, 1283360 free
So the uncompressed contents of the compressed image are 8 KB smaller,
whereas the resulting flash image (consisting of the compressed image
along with SEC, PEI_CORE and a set of PEIMs that execute in place) is
2 KB smaller.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2525
SafeUint64Mult() looks for 64-bit overflows and performs
several 32-bit multiples with 64-bit results to check for
all possible overflow conditions. IA32 builds using VS20xx
with optimizations enabled are producing a reference to
the _allmull intrinsic.
The fix is to use MultU64x64() instead of '*' for
these operations. These are safe because the inputs
are guaranteed to have the upper 32-bits clear, which
means MultU64x64() can never overflow with those inputs.
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: Bret Barkelew <bret.barkelew@microsoft.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
