Old implementation of RefreshMemoryAttributesFromMtrr directly
retrieves the MTRR register content and applies the MTRR cache type
to GCD database following the precedence order defined by SDM.
The code can updated to simply get all the memory cache types for all
memory through newly introduced API With the new introduced API
MtrrGetMemoryAttributesInMtrrSettings.
Benefits:
1. Remove the duplicated logic in CpuDxe driver that handles MTRR
details.
2. Let the MtrrLib to handle the case when fixed MTRR is absent.
(Old logic cannot handle the case.)
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
MtrrGetMemoryAttributesInMtrrSettings parses the MTRR settings
either from hardware or from the parameter and returns an
array containing the memory cache types of all memory addresses.
This API could elinimate the needs of following APIs:
1. MtrrGetMemoryAttributeInVariableMtr
2. MtrrGetFixedMtrr
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Update APIs related to set memory attributes to handle the fixed MTRR
is not always supported.
There are 3 APIs in MtrrLib that can set memory attributes:
1. MtrrSetMemoryAttributesInMtrrSettings
2. MtrrSetMemoryAttributeInMtrrSettings
3. MtrrSetMemoryAttribute
The general idea applied in MtrrSetMemoryAttributesInMtrrSettings is:
1. MtrrLibPreMtrrChange saves the old MTRR default type which
contains bit to enable fixed MTRR.
2. Main logic in MtrrSetMemoryAttributesInMtrrSettings applies
memory attribute settings for below 1MB to variable MTRRs
if fixed MTRR is not supported.
3. MtrrLibPostMtrrChange unconditionally sets E bit in MTRR default
type MSR but only set FE bit when fixed MTRRs are modified.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The patch fixes the following issues in the original implementation:
1. MtrrSetting contains random value if MTRR is not supported.
2. Unconditionally access fixed MTRR on CPU that may not support
fixed MTRR.
3. The maximum number of Variable MTRR entries are initialized, while
the portion exceeding the maximum number remains uninitialized.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Signed-off-by: Yuanhao Xie <yuanhao.xie@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Update UnitTestMtrrGetDefaultMemoryType for the case the when Fixed
MTRRs are not supported.
The original implementation returns FALSE when either fixed MTRR isn't
supported or the number of variable MTRRs is 0. The correct behavior
should return FALSE only when both fixed MTRR isn't supported and the
number of variable MTRRs is 0.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Update UnitTestGetFirmwareVariableMtrrCount for the case the when
Fixed MTRRs are not supported.
The original implementation returns FALSE when either fixed MTRR isn't
supported or the number of variable MTRRs is 0. The correct behavior
should return FALSE only when both fixed MTRR isn't supported and the
number of variable MTRRs is 0.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
The previous implementation returns FALSE if either fixed MTRR is
unsupported or the number of variable MTRRs is 0. The correct behavior
is to return FALSE only when both fixed MTRR is unsupported and the
number of variable MTRRs is 0.
Signed-off-by: Ray Ni <ray.ni@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
Trying to configure the TLS ciphers can lead to TLS handshake failures
because TlsCipherMappingTable is not in line with the ciphers actually
supported by OpensslLib.
Fix that by removing TlsCipherMappingTable altogether. Use
SSL_get_ciphers() instead to get the stack of ciphers supported by
openssl. Name and ID of the ciphers can be queried using the
SSL_CIPHER_get_name() and SSL_CIPHER_get_protocol_id() functions,
which allows us to map IDs to names without a hard-code table.
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=2541
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Message-Id: <20231004092003.3809321-1-kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Yi Li <yi1.li@intel.com>
FdtPL011SerialPortLib claims that it's usable from the DXE_CORE. That's
not correct: the DXE_CORE calls DEBUG() and ASSERT() before it calls
ProcessLibraryConstructorList(). Via the BaseDebugLibSerialPort instance,
those DEBUG() and ASSERT() calls result in SerialPortWrite() calls, before
ProcessLibraryConstructorList() called either our constructor
FdtPL011SerialPortLibInitialize(), or BaseDebugLibSerialPortConstructor().
(And even if the DXE_CORE called the latter function early enough, it
would just invoke our SerialPortInitialize() function -- which does
nothing.)
This means that the earliest DXE_CORE debug messages are lost.
Rename FdtPL011SerialPortLibInitialize() to SerialPortInitialize(), so
that the same initialization occur through the constructor and the public
SerialPortInitialize() library API.
Turn SerialPortInitialize() calls after the first one into no-ops.
Our SerialPortLib APIs already use (mSerialBaseAddress != 0) to track
initialization. Rework those checks to actually initialize the library if
that hasn't happened yet.
The following new lines appear in the log:
> CoreInitializeMemoryServices:
> BaseAddress - 0x48000000 Length - 0xF8000000 MinimalMemorySizeNeeded - 0x38C8000
> InstallProtocolInterface: [EfiLoadedImageProtocol] 46EFC3E0
> ProtectUefiImageCommon - 0x46EFC3E0
> - 0x0000000046EB2000 - 0x0000000000068000
(0x46EB2000 is the load address of the DXE Core.)
Reported-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
The ARM implementation of InternalLongJump always returned the value
Value - but it is not supposed to ever return 0. Add the test to prevent
that, and return 1 if Value is 0 - as is already present in AArch64.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Both in SetJump and in InternalLongJump, 32-bit w register views were
used for the UINTN return value. In SetJump, this did not cause errors;
it was only counterintuitive. But in InternalLongJump, it meant the top
32 bits of Value were stripped off.
Change all of these to use the 64-bit x register views.
Signed-off-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reanimated-by: Andrei Warkentin <andrei.warkentin@intel.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
Reviewed-by: Andrei Warkentin <andrei.warkentin@intel.com>
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2948
XhciDxe uses the timer functionality provided by the
boot services table to detect timeout conditions. This
breaks the driver's ExitBootServices call back, as
CoreExitBootServices halts the timer before signaling
the ExitBootServices event. If the host controller
fails to halt in the call back, the timeout condition
will never occur and the boot gets stuck in an indefinite
spin loop. Use the free running timer provided by
TimerLib to calculate timeouts, avoiding the potential
hang.
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Patrick Henz <patrick.henz@hpe.com>
Reviewed-by: Hao A Wu <hao.a.wu@intel.com>
Use AmlCodeGenRdQWordIo() to generate the I/O range in _CRS instead of
AmlCodeGenRdDWordIo() to cater to the scenarios where 64-bit addresses
can be used to generate I/O packets over the PCIe bus.
Signed-off-by: Jeff Brasen <jbrasen@nvidia.com>
Reviewed-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
