Bug #4414
Add DEBUG_MANAGEABILITY print error lever to
output debug message of detailed manageability
related module information, such as
- RedfishPkg:
- HTTP header/request/response
- JSON plain text
- Refish resource
- Redfish Host interface information
- Redfish credential information
- Platform configuration to Redfish mapping
- etc.
- ManageabilityPKg
- Protocol payload of MCTP/PLDM/IPMI
- Payload of transport interface transfers
- IPMI BLOB transfer
- etc.
- RedfishClinetPkg
- Redfish feature driver dispatcher
- Redfish BIOS attributes
- Platform configuration (HII) to
Redfish property information
- Redfish C structure information
- etc.
Signed-off-by: Abner Chang <abner.chang@amd.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Nickle Wang <nicklew@nvidia.com>
Cc: Igor Kulchytskyy <igork@ami.com>
Cc: Isaac Oram <isaac.w.oram@intel.com>
Cc: Abdul Lateef Attar <AbdulLateef.Attar@amd.com>
Cc: Tinh Nguyen <tinhnguyen@os.amperecomputing.com>
Add a new library, JedecJep106Lib which provides a service to return the
JEDEC JEP106 manufacturer string given the code and continuation bytes
values.
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
MdePkg.
Visual Studio versions before VS 2015 don't support __func__ and so
will fail to compile. A workaround is to define __func__ as
__FUNCTION__ :
#define __func__ __FUNCTION__
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Sunil V L <sunilvl@ventanamicro.com>
- Fix typos of "disable".
- Fix typos of "performance".
- Fix missing spaces.
- Use comma instead of period when the sentence continues on the next
line.
- Fix typo of "PERF_CORE_LOAD_IMAGE".
Signed-off-by: Rebecca Cran <rebecca@quicinc.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Bugzilla: 3668 (https://bugzilla.tianocore.org/show_bug.cgi?id=3668)
The NIST Special Publications 800-90A, 800-90B and 800-90C
provide recommendations for random number generation. The
NIST 800-90C, Recommendation for Random Bit Generator (RBG)
Constructions, defines the GetEntropy() interface that is
used to access the entropy source. The GetEntropy() interface
is further used by Deterministic Random Bit Generators (DRBG)
to generate random numbers.
The Arm True Random Number Generator (TRNG) library defines an
interface to access the entropy source on a platform, following
the 'Arm True Random Number Generator Firmware Interface'
specification.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
REF? https://bugzilla.tianocore.org/show_bug.cgi?id=3912
UefiCpuPkg define a new Protocol with the new services
SmmWaitForAllProcessor(), which can be used by SMI handler
to optionally wait for other APs to complete SMM rendezvous in
relaxed AP mode.
VariableSmm and VariableStandaloneMM driver in MdeModulePkg need
to use this services but MdeModulePkg can't depend on UefiCpuPkg.
Thus, the solution is moving SmmCpuRendezvouslib.h from UefiCpuPkg
to MdePkg and creating SmmCpuRendezvousLib NullLib version
implementation in MdePkg as dependency for the pkg that can't
depend on UefiCpuPkg.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Michael Kubacki <mikuback@linux.microsoft.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Zhihao Li <zhihao.li@intel.com>
Acked-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>
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>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2801
Add the UT_EXPECT_ASSERT_FAILURE(FunctionCall, Status) macro
to the UnitTestLib that can be used to check if a function
under test triggers an ASSERT() condition. If an ASSERT()
condition is triggered, then the macro returns. If the
ASSERT() condition is not triggered, then the current unit
test fails with a status of UNIT_TEST_ERROR_TEST_FAILED.
If ASSERT()s are disabled, then this check for ASSERT()
behavior is not possible, and the check is skipped.
The global variable gUnitTestExpectAssertFailureJumpBuffer
is added to the UnitTestLib to save/restore context when
the UT_EXPECT_ASSERT_FAILURE(FunctionCall, Status) macro
is used. The UT_EXPECT_ASSERT_FAILURE() macro uses the
SetJump() service with this global variable. The UnitTestLib
service UnitTestDebugAssert() uses the LongJump() service
with this global to restore context if an ASSERT() is
triggered by the code under test.
Add UnitTestExpectAssertFailure() to the UnitTestLib class.
The UnitTestExpectAssertFailure() is called from the new
UT_EXPECT_ASSERT_FAILURE() macro after the status of this
macro check is known.
Add UnitTestDebugAssert() to the UnitTestLib class. The
UnitTestDebugAssert() service is the same as the DebugLib
DebugAssert() service and is invoked from the DebugLib
_ASSERT() macro if unit testing is enabled. This allows the
Unit Test Framework to know when code under test triggers an
ASSERT() condition.
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>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1548
For clang compiler, This change will make the generated image not include the
absolute file path. If so, the generated debug image can be reproduced in the
different root directory. Also, it will reduce the size of debug image size.
To do so, use __FILE_NAME__ macro to replace __FILE__. __FILE_NAME__ is
Clang-specific extension that functions similar to __FILE__ but only renders
the last path component (the filename) instead of an invocation dependent full
path to that file, and __FILE_NAME__ is introduced since clang 9.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Signed-off-by: Zhiguang Liu <zhiguang.liu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=2505
Add UnitTestLib class to MdePkg that provides services
and macros to implement unit tests. These services and
macros support the following features:
* Create a Unit Test Framework
* Add a Unit Test Suite to a Unit Test Framework
+ Support optional step that executes before a Unit
Test Suite is started.
+ Support optional step that executes after a Unit
Test Suite is finished.
* Add a Unit Test to a Unit Test Suite
+ Support optional step that executes before a Unit
Test is started.
+ Support optional step that executes after a Unit
Test is finished.
* Run all unit tests added to a Unit Test Framework
* Save Unit Test Framework state to persistent storage
* Support assertion checks in a unit test for TRUE, FALSE,
EQUAL, MEM_EQUAL, NOT_EFI_ERROR, STATUS_EQUAL, and NOT_NULL.
* Support generation of log messages at ERROR, WARN, INFO,
and VERBOSE levels.
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: Bret Barkelew <Bret.Barkelew@microsoft.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
