Eric Dong [Wed, 2 Aug 2017 10:29:09 +0000 (18:29 +0800)]
UefiCpuPkg CpuDxe: Enhance get mtrr mask logic.
In order to not use the deprecated macro, refine
get mtrr mask value logic.
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Eric Dong [Wed, 2 Aug 2017 10:26:43 +0000 (18:26 +0800)]
QuarkSocPkg MtrrLib: Enhance get mtrr mask logic.
In order to not use the deprecated macro, refine
get mtrr mask value logic.
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
OvmfPkg/PlatformPei: support >=1TB high RAM, and discontiguous high RAM
In OVMF we currently get the upper (>=4GB) memory size with the
GetSystemMemorySizeAbove4gb() function.
The GetSystemMemorySizeAbove4gb() function is used in two places:
(1) It is the starting point of the calculations in GetFirstNonAddress().
GetFirstNonAddress() in turn
- determines the placement of the 64-bit PCI MMIO aperture,
- provides input for the GCD memory space map's sizing (see
AddressWidthInitialization(), and the CPU HOB in
MiscInitialization()),
- influences the permanent PEI RAM cap (the DXE core's page tables,
built in permanent PEI RAM, grow as the RAM to map grows).
(2) In QemuInitializeRam(), GetSystemMemorySizeAbove4gb() determines the
single memory descriptor HOB that we produce for the upper memory.
Respectively, there are two problems with GetSystemMemorySizeAbove4gb():
(1) It reads a 24-bit count of 64KB RAM chunks from the CMOS, and
therefore cannot return a larger value than one terabyte.
(2) It cannot express discontiguous high RAM.
Starting with version 1.7.0, QEMU has provided the fw_cfg file called
"etc/e820". Refer to the following QEMU commits:
Ever since these commits in v1.7.0 -- with the last QEMU release being
v2.9.0, and v2.10.0 under development --, the only two RAM entries added
to this E820 map correspond to the below-4GB RAM range, and the above-4GB
RAM range. And, the above-4GB range exactly matches the CMOS registers in
question; see the use of "pcms->above_4g_mem_size":
pc_q35_init() | pc_init1()
pc_memory_init()
e820_add_entry(0x100000000ULL, pcms->above_4g_mem_size, E820_RAM);
pc_cmos_init()
val = pcms->above_4g_mem_size / 65536;
rtc_set_memory(s, 0x5b, val);
rtc_set_memory(s, 0x5c, val >> 8);
rtc_set_memory(s, 0x5d, val >> 16);
Therefore, remedy the above OVMF limitations as follows:
(1) Start off GetFirstNonAddress() by scanning the E820 map for the
highest exclusive >=4GB RAM address. Fall back to the CMOS if the E820
map is unavailable. Base all further calculations (such as 64-bit PCI
MMIO aperture placement, GCD sizing etc) on this value.
At the moment, the only difference this change makes is that we can
have more than 1TB above 4GB -- given that the sole "high RAM" entry
in the E820 map matches the CMOS exactly, modulo the most significant
bits (see above).
However, Igor plans to add discontiguous (cold-plugged) high RAM to
the fw_cfg E820 RAM map later on, and then this scanning will adapt
automatically.
(2) In QemuInitializeRam(), describe the high RAM regions from the E820
map one by one with memory HOBs. Fall back to the CMOS only if the
E820 map is missing.
Again, right now this change only makes a difference if there is at
least 1TB high RAM. Later on it will adapt to discontiguous high RAM
(regardless of its size) automatically.
-*-
Implementation details: introduce the ScanOrAdd64BitE820Ram() function,
which reads the E820 entries from fw_cfg, and finds the highest exclusive
>=4GB RAM address, or produces memory resource descriptor HOBs for RAM
entries that start at or above 4GB. The RAM map is not read in a single
go, because its size can vary, and in PlatformPei we should stay away from
dynamic memory allocation, for the following reasons:
- "Pool" allocations are limited to ~64KB, are served from HOBs, and
cannot be released ever.
- "Page" allocations are seriously limited before PlatformPei installs the
permanent PEI RAM. Furthermore, page allocations can only be released in
DXE, with dedicated code (so the address would have to be passed on with
a HOB or PCD).
- Raw memory allocation HOBs would require the same freeing in DXE.
Therefore we process each E820 entry as soon as it is read from fw_cfg.
-*-
Considering the impact of high RAM on the DXE core:
A few years ago, installing high RAM as *tested* would cause the DXE core
to inhabit such ranges rather than carving out its home from the permanent
PEI RAM. Fortunately, this was fixed in the following edk2 commit:
3a05b13106d1, "MdeModulePkg DxeCore: Take the range in resource HOB for
PHIT as higher priority", 2015-09-18
Later on, OVMF was changed to install its high RAM as tested (effectively
"arming" the earlier DXE core change for OVMF), in the following edk2
commit:
035ce3b37c90, "OvmfPkg/PlatformPei: Add memory above 4GB as tested",
2016-04-21
Brijesh Singh [Wed, 2 Aug 2017 22:12:48 +0000 (18:12 -0400)]
OvmfPkg/QemuFwCfgLib: Use BusMasterCommonBuffer to map FW_CFG_DMA_ACCESS
Commit 09719a01b11b (OvmfPkg/QemuFwCfgLib: Implement SEV internal function
for Dxe phase) uses IOMMU protocol to allocate and free FW_CFG_DMA_ACCESS
buffer when SEV is active. During initial commits we made assumption that
IOMMU.AllocateBuffer() will provide PlainTextAddress (i.e C-bit cleared).
This assumption was wrong, the AllocateBuffer() protocol member is not
expected to produce a buffer that is immediatly usable, and client is
required to call Map() uncondtionally with BusMasterCommonBuffer[64] to
get a mapping which is accessable by both host and device.
The patch refactors code a bit and add the support to Map()
FW_CFG_DMA_ACCESS buffer using BusMasterCommonBuffer operation after
allocation and Unamp() before free.
The complete discussion about this and recommendation from Laszlo can be
found here [1]
Laszlo Ersek [Wed, 2 Aug 2017 18:31:08 +0000 (20:31 +0200)]
OvmfPkg/IoMmuDxe: Unmap(): recycle MAP_INFO after BusMasterCommonBuffer[64]
In order for Unmap() to be callable from ExitBootServices() event handler
context (for cleaning up a BusMasterCommonBuffer[64] operation), we have
to completely liberate the affected path in Unmap() from dynamic memory
management.
The last remaining piece is the release of the MAP_INFO structure. Rather
than freeing it with FreePool(), recycle it to an internal list. Elements
of this "free list" can be reused for any kind of Map() operation, and can
be freed later, or recycled again.
Laszlo Ersek [Wed, 2 Aug 2017 17:35:38 +0000 (19:35 +0200)]
OvmfPkg/IoMmuDxe: abort harder on memory encryption mask failures
Upon a MemEncryptSevClearPageEncMask() failure in Map(), it wouldn't be
difficult to release the bounce buffer that was implicitly allocated for
BusMasterRead[64] and BusMasterWrite[64] operations. However, undoing any
partial memory encryption mask changes -- partial page splitting and PTE
modifications -- is practically impossible. (For example, restoring the
encryption mask on the entire range has no reason to fare any better than
the MemEncryptSevClearPageEncMask() call itself.)
For this reason, keep ASSERT_EFI_ERROR(), but hang in RELEASE builds too,
if MemEncryptSevClearPageEncMask() or MemEncryptSevSetPageEncMask() fails.
Laszlo Ersek [Wed, 2 Aug 2017 16:26:59 +0000 (18:26 +0200)]
OvmfPkg/IoMmuDxe: implement in-place decryption/encryption for Map/Unmap
At the moment, we have the following distribution of actions between the
IOMMU protocol member functions:
- AllocateBuffer() allocates pages and clears the memory encryption mask.
- FreeBuffer() re-sets the memory encryption mask, and deallocates pages.
- Map() does nothing at all when BusMasterCommonBuffer[64] is requested
(and AllocateBuffer() was called previously). Otherwise, Map() allocates
pages, and clears the memory encryption mask.
- Unmap() does nothing when cleaning up a BusMasterCommonBuffer[64]
operation. Otherwise, Unmap() clears the encryption mask, and frees the
pages.
This is wrong: the AllocateBuffer() protocol member is not expected to
produce a buffer that is immediately usable, and client code is required
to call Map() unconditionally, even if BusMasterCommonBuffer[64] is the
desired operation. Implement the right distribution of actions as follows:
- AllocateBuffer() allocates pages and does not touch the encryption mask.
- FreeBuffer() deallocates pages and does not touch the encryption mask.
- Map() does not allocate pages when BusMasterCommonBuffer[64] is
requested, and it allocates pages (bounce buffer) otherwise. Regardless
of the BusMaster operation, Map() (and Map() only) clears the memory
encryption mask.
- Unmap() restores the encryption mask unconditionally. If the operation
was BusMasterCommonBuffer[64], then Unmap() does not release the pages.
Otherwise, the pages (bounce buffer) are released.
This approach also ensures that Unmap() can be called from
ExitBootServices() event handlers, for cleaning up
BusMasterCommonBuffer[64] operations. (More specifically, for restoring
the SEV encryption mask on any in-flight buffers, after resetting any
referring devices.) ExitBootServices() event handlers must not change the
UEFI memory map, thus any memory allocation or freeing in Unmap() would
disqualify Unmap() from being called in such a context.
Map()-ing and Unmap()-ing memory for a BusMasterCommonBuffer[64] operation
effectively means in-place decryption and encryption in a SEV context. As
an additional hurdle, section "7.10.8 Encrypt-in-Place" of AMD publication
Nr.24593 implies that we need a separate temporary buffer for decryption
and encryption that will eventually land in-place. Allocating said
temporary buffer in the straightforward way would violate the above
allocation/freeing restrictions on Map()/Unmap(), therefore pre-allocate
this "stash buffer" too in AllocateBuffer(), and free it in FreeBuffer().
To completely rid Unmap() of dynamic memory impact, for
BusMasterCommonBuffer[64] operations, we're going to rework the lifecycle of
the MAP_INFO structures in a later patch.
(The MemEncryptSevSetPageEncMask() call in Unmap() could theoretically
allocate memory internally for page splitting, however this won't happen
in practice: in Unmap() we only restore the memory encryption mask, and
don't genuinely set it. Any page splitting will have occurred in Map()'s
MemEncryptSevClearPageEncMask() call first.)
Laszlo Ersek [Wed, 2 Aug 2017 13:13:15 +0000 (15:13 +0200)]
OvmfPkg/IoMmuDxe: rework setup of "MapInfo->PlainTextAddress" in Map()
There are three issues with the current calculations:
- The initial logic that sets up "DmaMemoryTop" and "AllocateType" checks
for the BusMasterCommonBuffer64 operation in two places. The inner check
for BusMasterCommonBuffer64 will never evaluate to TRUE however, because
the outer check excludes BusMasterCommonBuffer64.
- In order to lower "DmaMemoryTop" to (SIZE_4GB - 1), the outer check
requires that the encrypted (original) buffer cross the 4GB mark. This
is wrong: for BusMasterRead[64] and BusMasterWrite[64] operations, we
unconditionally need a bounce buffer (a decrypted memory area), and for
the 32-bit variants, "DmaMemoryTop" should be lowered regardless of the
location of the original (encrypted) buffer.
- The current logic would be hard to extend for the in-place decryption
that we'll implement in the next patch.
Therefore rework the "MapInfo->PlainTextAddress" setup. No functional
changes beyond said bugfixes.
Laszlo Ersek [Wed, 2 Aug 2017 09:53:53 +0000 (11:53 +0200)]
OvmfPkg/IoMmuDxe: zero out pages before releasing them
Whenever we release the plaintext bounce buffer pages that were allocated
implicitly in Map() for BusMasterRead[64] and BusMasterWrite[64], we
restore the encryption mask on them. However, we should also rewrite the
area (fill it with zeros) so that the hypervisor is not left with a
plaintext view of the earlier data.
Similarly, whenever we release the plaintext common buffer pages that were
allocated explicitly in AllocateBuffer() for BusMasterCommonBuffer[64], we
restore the encryption mask on them. However, we should also rewrite the
area (fill it with zeros) so that the hypervisor is not left with a
plaintext view of the earlier data.
Laszlo Ersek [Wed, 2 Aug 2017 10:11:50 +0000 (12:11 +0200)]
OvmfPkg/IoMmuDxe: clean up used library classes
The following library classes are not used by this module, so remove them
from the INF file's [LibraryClasses] section:
- DxeServicesTableLib
- UefiLib
The following library classes are used by this module, so add them to the
INF file's [LibraryClasses] section:
- BaseMemoryLib (e.g. via CopyMem())
- MemoryAllocationLib (e.g. via AllocatePool())
Sort the list of library classes (in both "IoMmuDxe.inf" and
"AmdSevIoMmu.h").
Remove all non-local #include directives from "IoMmuDxe.c"; both C files
of this module include "AmdSevIoMmu.h", and "AmdSevIoMmu.h" includes all
non-local headers already.
Laszlo Ersek [Wed, 2 Aug 2017 09:42:14 +0000 (11:42 +0200)]
OvmfPkg/IoMmuDxe: convert UINTN arguments to UINT64 for the %Lx fmt spec
The portable way to print UINTN values is to use the %Lx format specifier,
and to convert the values to UINT64. The second step is currently missing,
add it.
Laszlo Ersek [Wed, 2 Aug 2017 09:26:42 +0000 (11:26 +0200)]
OvmfPkg/IoMmuDxe: rename DeviceAddress to PlainTextAddress in MAP_INFO
In this particular IOMMU driver, "DeviceAddress" is just as accessible to
the CPU as "HostAddress", the difference is that the area pointed-to by
the former is plain-text and accessible to the hypervisor. Rename
"DeviceAddress" to "PlainTextAddress" in MAP_INFO.
In a form, some new menus may be dynamically inserted between highlight
menu and previous top of screen menu when some question are refreshed.
So the highlight menu and previous top of screen menu perhaps can't be
shown in one page. Existing codes miss to handle this case then will
cause incorrect display.This patch is to fix this display issue.
Cc: Eric Dong <eric.dong@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Fu Siyuan [Thu, 3 Aug 2017 06:38:51 +0000 (14:38 +0800)]
NetworkPkg: iSCSI should allow to set 6 or 12 length of ISID keyword.
The last 3 bytes of ISID should be able to changed by setting the keyword with
a value with length 6 (only last 3 bytes) or 12 (full ISID) according to the
keyword definition in UEFI configuration namespace website.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
Eric Dong [Fri, 4 Aug 2017 01:59:08 +0000 (09:59 +0800)]
UefiCpuPkg: Enable Processor Trace feature.
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Eric Dong [Wed, 19 Jul 2017 01:00:30 +0000 (09:00 +0800)]
UefiCpuPkg: Add Pcds used by processor trace feature.
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Hao Wu [Wed, 2 Aug 2017 08:15:53 +0000 (16:15 +0800)]
UefiCpuPkg/Msr: Add a missing IvyBridge processor signature
This commit modifies the CPUID signature check MACRO for IvyBridge
processor by adding a missing DisplayModel 0x3E. The missing one appears
at Section 35.10.1 to Section 35.10.3 of the Intel(R) 64 and IA-32
Architectures Software Developer's Manual, Volume 3, September 2016.
Star Zeng [Tue, 1 Aug 2017 05:47:08 +0000 (13:47 +0800)]
MdeModulePkg PeiCore: Install SEC HOB data
If the EFI_SEC_HOB_DATA_PPI is in the list of PPIs passed to the PEI
entry point, the PEI Foundation will call the GetHobs() member
function and install all HOBs returned into the HOB list. It does
this after installing all PPIs passed from SEC into the PPI database
and before dispatching any PEIMs.
Eric Dong [Thu, 20 Jul 2017 12:07:46 +0000 (20:07 +0800)]
UefiCpuPkg PiSmmCpuDxeSmm: Check LMCE capability when wait for AP.
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Eric Dong [Thu, 20 Jul 2017 12:05:43 +0000 (20:05 +0800)]
UefiCpuPkg: Add definition for LMCE feature.
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eric Dong <eric.dong@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Andrew Fish <afish@apple.com> Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Add Readme.md with a brief description of the EDK II
open source project along with links to contribution
agreement, licenses, and resources.
Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Andrew Fish <afish@apple.com> Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Add top level License.txt file with the BSD 2-Clause
License that is used by the majority of the EKD II open
source project content. Merge copyright statements
from the BSD 2-Clause License files in each package
directory and remove the duplication License.txt
file from package directories.
Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Andrew Fish <afish@apple.com> Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Update formatting of Contributions.txt to line wrap
at 80 columns.
Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Andrew Fish <afish@apple.com> Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Update the TianoCore Contribution Agreement from Version 1.0
to Version 1.1 to cover open source documentation associated
with the TianoCore project.
Version 1.0 covers source code files. Version 1.1 is a
backwards compatible extension that adds support for document
files in both source form and compiled form.
The edk2 repository is updated so the same contribution
agreement is used by developers that work on TianoCore
related source code or TianoCore related documents.
Links to RFC and Wiki on the GitBook documentation process
* https://lists.01.org/pipermail/edk2-devel/2017-March/008654.html
* https://github.com/tianocore-docs/edk2-TemplateSpecification/wiki
Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Andrew Fish <afish@apple.com> Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Move Contributions.txt that contains the TianoCore
Contribution Agreement 1.0 to the root of the edk2
repository and remove the duplicate Contributions.txt
files from all packages.
Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Andrew Fish <afish@apple.com> Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Update PatchCheck.py to support either
"Contributed-under: TianoCore Contribution Agreement 1.0"
or "Contributed-under: TianoCore Contribution Agreement 1.1"
in the commit message.
Temporarily continue to allow the TianoCore Contribution
Agreement 1.0 agreement.
Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Andrew Fish <afish@apple.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Fu Siyuan [Wed, 26 Jul 2017 07:57:38 +0000 (15:57 +0800)]
NetworkPkg: Display HTTP redirection info to the screen if need.
HTTP defines a set of status code for redirecting a request to a different URI
in Section 6.4 of RFC7231 and also RFC7583. This patch updates the HTTP boot
driver to display the redirection info to the screen so the user would have
chance to know new URI address of the HTTP boot image.
Hao Wu [Thu, 15 Jun 2017 07:15:59 +0000 (15:15 +0800)]
MdeModulePkg/Ufs: Set 'Data Segment Length' field for Write Descriptor
According to the Universal Flash Storage (UFS) Version 2.1 (JESD220C) spec
Section 10.7.8.5, the DATA SEGMENT LENGTH field of the UPIU shall also be
set to number of descriptor bytes to write.
MdePkg/Ftp4: Fix wrong function pointer declaration
EFI_FTP4_DATA_CALLBACK is a function pointer and defined as follows:
> typedef
> EFI_STATUS
> (EFIAPI *EFI_FTP4_DATA_CALLBACK)(
> IN EFI_FTP4_PROTOCOL *This,
> IN EFI_FTP4_COMMAND_TOKEN *Token
> );
And EFI_FTP4_COMMAND_TOKEN structure declared it as:
> EFI_FTP4_DATA_CALLBACK *DataCallback
Which ended up being a pointer to function pointer and clearly wrong.
This patch fixes it by removing the misleading '*' from declaration.
It's also fixed in new UEFI 2.7 spec.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Paulo Alcantara <paulo.alc.cavalcanti@hp.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
CryptoPkg/TlsLib: Remove the redundant free of BIO objects
TLS BIO objects (InBio/OutBio) will be freed by SSL_free() function.
So, the following free operation (BIO_free) in TlsFree is redundant.
It can be removed directly.
Cc: Ye Ting <ting.ye@intel.com> Cc: Long Qin <qin.long@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Long Qin <qin.long@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
NetworkPkg/Ip6Dxe: Fix the IPv6 PXE boot option goes missing issue
This patch is to fix the potential issue recorded at Bugzilla 636:
https://bugzilla.tianocore.org/show_bug.cgi?id=636
The issue is caused by the IPv6 policy switching after PXEv6 boot. When IP
policy is changing, the IPv6 children used by PXE.UdpRead() will be destroyed.
Then, PXE Stop() function is called to uninstall the devicePath protocol,
which leads to the IPv6 PXE boot option goes missing.
Through the above analysis, the IP driver should take the responsibility for
the upper layer network stacks recovery by using ConnectController().
Cc: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com> Cc: Subramanian Sriram <sriram-s@hpe.com> Cc: Ni Ruiyu <ruiyu.ni@intel.com> Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com> Reviewed-by: Subramanian Sriram <sriram-s@hpe.com> Tested-by: Hegde Nagaraj P <nagaraj-p.hegde@hpe.com>
Star Zeng [Fri, 28 Jul 2017 02:05:19 +0000 (10:05 +0800)]
MdeModulePkg FirmwarePerfPei: Remove SEC performance data getting code
Current SEC performance data getting code in FirmwarePerformancePei
may get wrong SEC performance data if FirmwarePerformancePei executes
after memory discovered.
And as SecCore has added SecPerformancePpiCallBack to get SEC performance
data and build HOB to convey the SEC performance data to DXE phase.
This patch is to remove the SEC performance data getting code in
FirmwarePerformancePei.
Star Zeng [Fri, 28 Jul 2017 02:05:08 +0000 (10:05 +0800)]
UefiCpuPkg SecCore: Add SecPerformancePpiCallBack
Add SecPerformancePpiCallBack to get SEC performance data and
build HOB to convey the SEC performance data to DXE phase.
Cc: Liming Gao <liming.gao@intel.com> Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Star Zeng [Fri, 28 Jul 2017 14:13:00 +0000 (22:13 +0800)]
UefiCpuPkg SecCore: Adjust PeiTemporaryRamBase&Size to be 8byte aligned
As HOB which has 8byte aligned requirement will be built based on them
in PEI phase.
Cc: Liming Gao <liming.gao@intel.com> Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Star Zeng [Fri, 28 Jul 2017 03:44:54 +0000 (11:44 +0800)]
MdeModulePkg PiSmmCoreMemoryAllocLib: Fix a FreePool() assertion issue
When PiSmmCore links against PeiDxeDebugLibReportStatusCode, the code
flow below will cause a FreePool() assertion issue.
PiSmmCoreMemoryAllocationLibConstructor() ->
SmmInitializeMemoryServices() ->
DEBUG ((DEBUG_INFO, "SmmAddMemoryRegion\n")) in SmmAddMemoryRegion() ->
DebugPrint() -> REPORT_STATUS_CODE_EX() -> ReportStatusCodeEx() ->
AllocatePool()/FreePool(PiSmmCoreMemoryAllocLib) ->
ASSERT() at Head = CR (Buffer, POOL_HEAD, Data, POOL_HEAD_SIGNATURE)
in CoreFreePoolI() of DxeCore Pool.c
It is because at the point of FreePool() in the code flow above,
mSmmCoreMemoryAllocLibSmramRanges/mSmmCoreMemoryAllocLibSmramRangeCount
are not been initialized yet, the FreePool() will be directed to
gBS->FreePool(), that is wrong.
This patch is to temporarily use BootServicesData to hold the
SmramRanges data before calling SmmInitializeMemoryServices().
BaseTools: Fix the bug to correctly check Pcd type that in FDF file
We set Pcd value in FDF and used this Pcd as PatchableInModule type in
module, it cause build report generate failure. because we incorrectly
set the Pcd type during check whether the Pcd is used.
Ruiyu Ni [Thu, 27 Jul 2017 03:05:16 +0000 (11:05 +0800)]
MdeModulePkg/PciBus: Avoid hang when BUS pad resource is not in top
PciScanBus() assumes the GetResourcePadding() puts BUS descriptor
in the very beginning, if it's not, the Descriptors will be updated
to point to middle of the pool buffer, which can cause
FreePool(Descriptors) hang in DEBUG image.
No functionality impact to RELEASE image.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Ruiyu Ni [Wed, 26 Jul 2017 08:21:54 +0000 (16:21 +0800)]
ShellPkg: Avoid buffer out-of-bound access
PathSize is the number of bytes in PathForReturn buffer so
PathForReturn[PathSize - 1] incorrectly accesses the last
character in the buffer,
PathForReturn[PathSize / sizeof (CHAR16) - 1] should be used.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Steven Shi <steven.shi@intel.com>
Star Zeng [Thu, 20 Jul 2017 06:47:28 +0000 (14:47 +0800)]
MdePkg: Follow UEFI 2.7 spec to deprecate SMM Communication ACPI Table
Delete PiSmmCommunicationAcpiTable.h and delete SMM Communication ACPI
Table definition in UefiAcpiDataTable.h.
As EFI_SMM_COMMUNICATE_HEADER is defined in both PI spec vol 4
and UEFI spec, move its definition to SmmCommunication.h.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Star Zeng [Thu, 20 Jul 2017 06:57:12 +0000 (14:57 +0800)]
UefiCpuPkg PiSmmCommunicationSmm: Deprecate SMM Communication ACPI Table
Follow UEFI 2.7 spec to deprecate SMM Communication ACPI Table,
PiSmmCommunicationSmm will not install SMM Communication ACPI Table
anymore.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
MdeModulePkg/BMMUiLib: Check reset requirement before exiting UiApp
V2: Refine the comments.
In UI page, some configuration change may require system reset.
BootMaintenanceManagerUiLib misses this check before exiting UiApp
to boot other boot options. Now add the check.
MdeModulePkg/BMUiLib: Check reset requirement before exiting UiApp
V2: Refine the comments.
In UI page, some configuration change may require system reset.
BootManagerUiLib misses this check before exiting UiApp to boot
other boot options. Now add the check.
MdeModulePkg/SetupBrowser: Record the reset status in all SendForm
After calling SendForm to enter front page, configuration change in some
driver may require system reset. Currently the reset status is saved in
SendForm level. Then SendForm can return the reset status.
IsResetRequired API also can return the reset status before exiting browser.
It return the reset status in current SendForm level now. But SendForm can
be recursive called by some module.so the reset status in previous SendForm
may be lost. Now change the IsResetRequired API to return the reset info no
matter the reset is caught in any SendForm.
But for other case, PcdMaxVariableSize is also required with the value
of 0x2000 (e,g. NetworkPkg/IScsiDxe), so remove the condition of
PcdMaxVariableSize for NT32 platform.
4.10.2.4 Babble Detected Error
When a device transmits more data on the USB than the host controller
is expecting for a transaction, it is defined to be babbling.
In general, this is called a Babble Error. When a device sends more
data than the TD Transfer Size bytes (TD Babble), unexpected activity
that persists beyond a specified point in a (micro)frame (Frame Babble),
or a packet greater than Max Packet Size (Packet Babble), the host
controller shall set the Babble Detected Error in the Completion Code
field of the TRB, generate an Error Event, and halt the endpoint
(refer to Section 4.10.2.1).
This patch is to also check for EFI_USB_ERR_BABBLE error returned as
a TransferResult and then proceed to XhcRecoverhaltedEndPoint.
Cc: Vladimir Olovyannikov <vladimir.olovyannikov@broadcom.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Currently, SmmCommunciate fails in RestoreLockBox after
SmmReadyToLock since COMM buffer is in stack instead of
using SmmCommRegion by gEdkiiPiSmmCommunicationRegionTableGuid.
This patch is to get SmmCommRegion by
gEdkiiPiSmmCommunicationRegionTableGuid for COMM buffer
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Baraneedharan Anbazhagan <anbazhagan@hp.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Ruiyu Ni [Wed, 19 Jul 2017 09:14:28 +0000 (17:14 +0800)]
MdePkg/ResetNotification: Rename to UnregisterResetNotify
UEFI Spec uses UnRegisterResetNotify in protocol structure
definition but uses UnregisterResetNotify in the function
prototype definition.
By searching the entire spec, Unregister* is used for
SIMPLE_TEXT_INPUT_EX_PROTOCOL.UnregisterKeyNotify(). So choose
to use UnregisterResetNotify for consistency.
projects / mirror_edk2.git / log