Jeff Westfahl [Thu, 4 May 2017 21:53:04 +0000 (05:53 +0800)]
ShellPkg/HandleParsingLib: Show LoadedImageProtocol file name
This patch adds support for showing the file name associated with a
LoadedImageProtocol file path. This is a behavior that was present in
the old shell but has been lost in the new shell.
Jeff Westfahl [Thu, 4 May 2017 21:53:03 +0000 (05:53 +0800)]
ShellPkg/HandleParsingLib: Open LoadedImageProtocol first
This patch changes the order of operations to make sure we can open the
LoadedImageProtocol before getting the format string. This should not
affect functionality, and makes the next patch easier to review.
Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
Jeff Westfahl [Thu, 4 May 2017 21:53:02 +0000 (05:53 +0800)]
ShellPkg/HandleParsingLib: Show LoadedImageProtocol file path as text
This patch adds support for displaying a text representation of the file
path associated with a LoadedImageProtocol. This is a behavior that was
present in the old shell but has been lost in the new shell.
Jeff Fan [Thu, 11 May 2017 07:01:39 +0000 (15:01 +0800)]
UefiCpuPkg/PiSmmCpuDxeSmm: Fix logic check error
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
If PcdCpuHotPlugSupport is TRUE, gSmst->NumberOfCpus will be the
PcdCpuMaxLogicalProcessorNumber. If gSmst->SmmStartupThisAp() is invoked for
those un-existed processors, ASSERT() happened in ConfigSmmCodeAccessCheck().
This fix is to check if ProcessorId is valid before invoke
gSmst->SmmStartupThisAp() in ConfigSmmCodeAccessCheck() and to check if
ProcessorId is valid in InternalSmmStartupThisAp() to avoid unexpected DEBUG
error message displayed.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Jeff Fan [Wed, 10 May 2017 06:47:03 +0000 (14:47 +0800)]
UefiCpuPkg/SmmCpuFeaturesLib: Correct print level
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Fan <jeff.fan@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Jiaxin Wu [Wed, 10 May 2017 15:30:57 +0000 (23:30 +0800)]
NetworkPkg/IScsiDxe: Switch IP4 configuration policy to Static before DHCP
DHCP4 service allows only one of its children to be configured in the active
state. If the DHCP4 D.O.R.A started by IP4 auto configuration and has not
been completed, the Dhcp4 state machine will not be in the right state for
the iSCSI to start a new round D.O.R.A. So, we need to switch it's policy to
static.
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: Ye Ting <ting.ye@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Remove the functions now provided by TimeBaseLib from
PL031RealTimeClockLib. Add TimeBaseLib resolution to ArmVirtPkg
in same commit to prevent breakage.
Some generic RTC helper functions were broken out from the PL031
library for use with other RTCs in OpenPlatformPkg. Import the code back
here, realigning it with the current state of PL031RealTimeClockLib to
simplify comparisons.
Jiaxin Wu [Fri, 5 May 2017 01:01:08 +0000 (09:01 +0800)]
Nt32Pkg/SnpNt32Dxe: Fix hang issue when multiple network interfaces existed
Currently all the network interfaces share the one recycled transmit buffer
array, which is used to store the recycled buffer address. However, those
recycled buffers are allocated by the different MNP interface if the multiple
network interfaces existed. Then, SNP GetStatus may return one recycled transmit
buffer address to the another MNP interface, which may result in the MNP driver
hang after 'reconnect -r' operation.
Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Zhang Lubo [Thu, 4 May 2017 09:35:36 +0000 (17:35 +0800)]
NetworkPkg: Fix issue in dns driver when building DHCP packet.
Currently, DNS driver configure the dhcp message type to inform
when building dhcp packet to get dns info from, but it not works
with dhcp server deployed on linux system. However it works well
when changed to request type.
Fu Siyuan [Wed, 3 May 2017 07:22:08 +0000 (15:22 +0800)]
MdeModulePkg: Addressing TCP Window Retraction when window scale factor is used.
The RFC1323 which defines the TCP window scale option has been obsoleted by RFC7323.
This patch is to follow the RFC7323 to address the TCP window retraction problem
when a non-zero scale factor is used.
The changes has been test in high packet loss rate network by using HTTP boot and
iSCSI file read/write.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
Fu Siyuan [Wed, 3 May 2017 06:30:36 +0000 (14:30 +0800)]
NetworkPkg: Addressing TCP Window Retraction when window scale factor is used.
The RFC1323 which defines the TCP window scale option has been obsoleted by RFC7323.
This patch is to follow the RFC7323 to address the TCP window retraction problem
when a non-zero scale factor is used.
The changes has been test in high packet loss rate network by using HTTP boot and
iSCSI file read/write.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
Fu Siyuan [Wed, 3 May 2017 07:21:23 +0000 (15:21 +0800)]
MdeModulePkg: Add wnd scale check before shrinking window.
Moving Right window edge to the left on sender side without additional check
can lead to the TCP deadlock, when receiver ACKs proper segment, while sender
discards it for future ACK. To prevent this add check if usable window (or
shrink amount in this case) is bigger then receiver's window scale factor.
Fu Siyuan [Wed, 3 May 2017 06:20:56 +0000 (14:20 +0800)]
NetworkPkg: Add wnd scale check before shrinking window.
Moving Right window edge to the left on sender side without additional check
can lead to the TCP deadlock, when receiver ACKs proper segment, while sender
discards it for future ACK. To prevent this add check if usable window (or
shrink amount in this case) is bigger then receiver's window scale factor.
Ruiyu Ni [Fri, 5 May 2017 02:10:00 +0000 (10:10 +0800)]
UefiCpuPkg/MtrrLib: Don't report OutOfResource when MTRR is enough
The MTRR calculation algorithm contains a bug that when left
subtraction cannot produce better MTRR solution, it forgets
to restore the BaseAddress/Length so that MtrrLibGetMtrrNumber()
returns bigger value of actual required MTRR numbers.
As a result, the MtrrLib reports OutOfResource but actually the
MTRR is enough.
The FvHandle input to InternalGetSectionFromFv() may be NULL,
then ASSERT will appear. It is because the LoadedImage->DeviceHandle
returned from InternalImageHandleToFvHandle() may be NULL.
For example for DxeCore, there is LoadedImage protocol installed
for it, but the LoadedImage->DeviceHandle could not be initialized
before the FV2 (contain DxeCore) protocol is installed.
This patch is to update InternalGetSectionFromFv() to return
EFI_NOT_FOUND directly for NULL FvHandle.
Cc: Liming Gao <liming.gao@intel.com> Cc: Michael Kinney <michael.d.kinney@intel.com> Cc: Michael Turner <Michael.Turner@microsoft.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Laszlo Ersek [Fri, 5 May 2017 00:35:21 +0000 (02:35 +0200)]
OvmfPkg/PlatformPei: handle non-power-of-two spare size for emu variables
In commit b24fca05751f ("OvmfPkg: introduce 4MB flash image (mainly) for
Windows HCK", 2017-04-29), I changed PcdFlashNvStorageFtwSpareSize to
264KB, in the then-new default 4MB build.
While PcdFlashNvStorageFtwSpareSize remains exactly half of the entire
non-volatile store (which is 528KB), 264KB isn't itself a power of two.
This triggers an assertion failure in AllocateAlignedRuntimePages() when
PlatformPei calls it from the ReserveEmuVariableNvStore() function,
passing PcdFlashNvStorageFtwSpareSize as the Alignment parameter:
The 264KB size introduced for the NV spare area in commit b24fca05751f
("OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK",
2017-04-29) breaks the "-bios" (emulated varstore) use case. Until we sort
that out, revert the default build to the 2MB image.
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
OvmfPkg: raise max variable size (auth & non-auth) to 33KB for FD_SIZE_4MB
The "ConfirmSetOfLargeVariable" test case of the Secure Boot Logo Test
("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware
Certification Kit sets a 32 KB large non-authenticated variable.
In the FD_SIZE_4MB build, our live varstore is now 256 KB big, so we can
accommodate this. Set both PcdMaxVariableSize and PcdMaxAuthVariableSize
to 0x8400 -- beyond DataSize=0x8000 from the HCK test, we need some room
for the variable name and attributes as well.
Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK
The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the
Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the
Microsoft Hardware Certification Kit expects to be able to populate the
variable store up to roughly 64 KB, with a series of 1 KB sized,
unauthenticated variables. OVMF's current live varstore area is too small
for this: 56 KB.
Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096),
which
- enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see
FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --,
- inside that, grows the varstore area / pflash chip to 528 KB, and within
it, the live area from 56 KB to 256 KB.
Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be
compatible with a variable store that originates from a variable store
template built *without* -D FD_SIZE_4MB. This is the reason for the large
increase, as every such change breaks compatibility between a new firmware
binary and old varstore files.
Enlarging the varstore does not impact the performance of normal
operations, as we keep the varstore block size 4KB. The performance of
reclaim is affected, but that is expected (since reclaim has to rework the
full live area). And, reclaim occurs proportionally less frequently.
While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in
it) is also enlarged significantly, so that we have plenty of room for
future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing
steadily, and that increase shows through compression too. Right now the
PEIFV and DXEFV volumes need no resizing.
Here's a summary:
Description Compression type Size [KB]
------------------------- ----------------- ----------------------
Non-volatile data storage open-coded binary 128 -> 528 ( +400)
data
Variable store 56 -> 256 ( +200)
Event log 4 -> 4 ( +0)
Working block 4 -> 4 ( +0)
Spare area 64 -> 264 ( +200)
Laszlo Ersek [Wed, 3 May 2017 15:54:49 +0000 (17:54 +0200)]
OvmfPkg: introduce the FD_SIZE_IN_KB macro / build flag
FD_SIZE_xMB defines have existed for flash size selection. They can be
passed as "-D FD_SIZE_xMB" on the command line. Passing multiple of them
at the same time has never been supported; earlier settings on the command
line cannot be overridden.
Introduce the integer valued FD_SIZE_IN_KB macro, which provides the
following improvements:
- several instances of it are permitted on the command line, with the last
one taking effect,
- conditional statements in the DSC and FDF files need only check a single
macro, and multiple values can be checked in a single !if with the ||
operator,
- nested !ifdef / !else ladders can be replaced with flat equality tests,
- in the future, flash sizes can be expressed with a finer than MB
granularity, if necessary.
For now, we're going to preserve the FD_SIZE_xMB defines as convenience
wrappers for FD_SIZE_IN_KB.
FD_SIZE_IN_KB is being added to the DSC files because this way we can
depend on it in both the DSC and FDF files.
Cc: Gary Ching-Pang Lin <glin@suse.com> Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
NetworkPkg: Fix PXEv6 boot failure when DhcpBinl offer received.
In case of the DHCP and PXE services on different servers,PXEv6 boot will
failure when DhcpBinl offer received. The issue is caused by the following
reasons:
* PXE Client doesn't append VENDOR_CLASS request parameter, so the
offer replied from DHCP service will not contain VENDOR_CLASS option
(16).
* Once the DhcpBinl offer is selected, the boot discover message should
be sent out to request the bootfile by this offer. Current implementation
always use servers multi-cast address instead of BootFileUrl address in
dhcp6 offer. we should check it first, then decide whether use multi-cast
address or not.
* If DhcpBinl offer is selected, the boot discover message shouldn't
find server ID Option from DhcpBinl offer. That's incorrect because DHCP
service and PXE service on different servers. In such a case, we can ignore
the Server ID Option.
With the above fix in the patch, PXEv6 can boot successfully when DhcpBinl
offer received.
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: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
NetworkPkg: Fix bug in iSCSI mode ipv6 when enabling target DHCP.
if the server name expressed as a site local address begain with FEC0
when retrieving from dhcpv6 option 59 boot file url, it incorrectly process it
as a dns name.
NetworkPkg: Fix issue the iSCSI client can not send reset packet.
if we already established a iSCSI connection from initiator to target
based on IPv4 stack, after using reconnect -r command, we can not rebuild
the session with the windows target, since the server thought the session
is still exist. This issue is caused by wrong place of acquire ownership of
sock lock which lead the iSCSI can not reset the connection correctly.
MdeModulePkg: Fix issue the iSCSI client can not send reset packet correctly.
if we already established a iSCSI connection from initiator to target
based on IPv4 stack, after using reconnect -r command, we can not rebuild
the session with the windows target, since the server thought the session
is still exist. This issue is caused by wrong place of acquire ownership of
sock lock which lead the iSCSI can not reset the connection correctly.
ShellPkg/Shell: eliminate double-free in RunSplitCommand()
Commit bd3fc8133b2b ("ShellPkg/App: Fix memory leak and save resources.",
2016-05-20) added a FreePool() call for Split->SplitStdIn, near end of the
RunSplitCommand(), right after the same shell file was closed with
CloseFile(). The argument was:
> 1) RunSplitCommand() allocates the initial SplitStdOut via
> CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix
> the memory leak.
There is no memory leak actually, and the FreePool() call in question
constitutes a double-free:
CreateFileInterfaceMem() allocates an EFI_FILE_PROTOCOL_MEM object and
populates it fully. ConvertEfiFileProtocolToShellHandle() allocates
some administrative structures and links the EFI_FILE_PROTOCOL_MEM
object into "mFileHandleList".
(b) EFI_SHELL_PROTOCOL.CloseFile() is required to close the
SHELL_FILE_HANDLE and to release all associated data. Accordingly,
near the end of RunSplitCommand(), we have:
EfiShellClose()
ShellFileHandleRemove()
//
// undoes the effects of ConvertEfiFileProtocolToShellHandle()
//
ConvertShellHandleToEfiFileProtocol()
//
// note that this does not adjust the pointer value; it's a pure
// type cast
//
FileHandleClose()
FileInterfaceMemClose()
//
// tears down EFI_FILE_PROTOCOL_MEM completely, undoing the
// effects of CreateFileInterfaceMem ()
//
The FreePool() call added by bd3fc8133b2b conflicts with
SHELL_FREE_NON_NULL(This);
in FileInterfaceMemClose(), so remove it.
This error can be reproduced for example with:
> Shell> map | more
> 'more' is not recognized as an internal or external command, operable
> program, or script file.
which triggers:
> ASSERT MdeModulePkg/Core/Dxe/Mem/Pool.c(624): CR has Bad Signature
with the following stack dump:
> #0 0x000000007f6dc094 in CpuDeadLoop () at
> MdePkg/Library/BaseLib/CpuDeadLoop.c:37
> #1 0x000000007f6dd1b4 in DebugAssert (FileName=0x7f6ed9f0
> "MdeModulePkg/Core/Dxe/Mem/Pool.c", LineNumber=624,
> Description=0x7f6ed9d8 "CR has Bad Signature") at
> OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c:153
> #2 0x000000007f6d075d in CoreFreePoolI (Buffer=0x7e232c98,
> PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:624
> #3 0x000000007f6d060e in CoreInternalFreePool (Buffer=0x7e232c98,
> PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:529
> #4 0x000000007f6d0648 in CoreFreePool (Buffer=0x7e232c98) at
> MdeModulePkg/Core/Dxe/Mem/Pool.c:552
> #5 0x000000007d49fbf8 in FreePool (Buffer=0x7e232c98) at
> MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:818
> #6 0x000000007d4875c3 in RunSplitCommand (CmdLine=0x7d898398,
> StdIn=0x0, StdOut=0x0) at ShellPkg/Application/Shell/Shell.c:1813
> #7 0x000000007d487d59 in ProcessNewSplitCommandLine
> (CmdLine=0x7d898398) at ShellPkg/Application/Shell/Shell.c:2121
> #8 0x000000007d488937 in RunShellCommand (CmdLine=0x7e233018,
> CommandStatus=0x0) at ShellPkg/Application/Shell/Shell.c:2670
> #9 0x000000007d488b0b in RunCommand (CmdLine=0x7e233018) at
> ShellPkg/Application/Shell/Shell.c:2732
> #10 0x000000007d4867c8 in DoShellPrompt () at
> ShellPkg/Application/Shell/Shell.c:1349
> #11 0x000000007d48524d in UefiMain (ImageHandle=0x7e24c898,
> SystemTable=0x7f5b6018) at ShellPkg/Application/Shell/Shell.c:631
ShellPkg/Shell: clean up bogus member types in SPLIT_LIST
The "SPLIT_LIST.SplitStdOut" and "SPLIT_LIST.SplitStdIn" members currently
have type (SHELL_FILE_HANDLE *). This is wrong; SHELL_FILE_HANDLE is
already a pointer, there's no need to store a pointer to a pointer.
The error is obvious if we check where and how these members are used:
- In the RunSplitCommand() function, these members are used (populated)
extensively; this function has to be updated in sync.
ConvertEfiFileProtocolToShellHandle() already returns the temporary
memory file created with CreateFileInterfaceMem() as SHELL_FILE_HANDLE,
not as (SHELL_FILE_HANDLE *).
- In particular, the ConvertShellHandleToEfiFileProtocol() calls need to
be dropped as well in RunSplitCommand(), since
EFI_SHELL_PROTOCOL.SetFilePosition() and EFI_SHELL_PROTOCOL.CloseFile()
take SHELL_FILE_HANDLE parameters, not (EFI_FILE_PROTOCOL *).
Given that ConvertShellHandleToEfiFileProtocol() only performs a
type-cast (it does not adjust any pointer values), *and*
SHELL_FILE_HANDLE -- taken by EFI_SHELL_PROTOCOL member functions -- is
actually a typedef to (VOID *) -- see more on this later --, this
conversion error hasn't been caught by compilers.
- In the ProcessNewSplitCommandLine() function, RunSplitCommand() is
called either initially (passing in NULL / NULL; no update needed), or
recursively (passing in Split->SplitStdIn / Split->SplitStdOut; again no
update is necessary beyond the RunSplitCommand() modification above).
- In the UpdateStdInStdOutStdErr() and RestoreStdInStdOutStdErr()
functions, said structure members are compared and assigned to
"EFI_SHELL_PARAMETERS_PROTOCOL.StdIn" and
"EFI_SHELL_PARAMETERS_PROTOCOL.StdOut", both of which have type
SHELL_FILE_HANDLE, *not* (SHELL_FILE_HANDLE *).
The compiler hasn't caught this error because of the fatally flawed type
definition of SHELL_FILE_HANDLE, namely
typedef VOID *SHELL_FILE_HANDLE;
Pointer-to-void silently converts to and from most other pointer types;
among them, pointer-to-pointer-to-void. That is also why no update is
necessary for UpdateStdInStdOutStdErr() and RestoreStdInStdOutStdErr()
in this fix.
(
Generally speaking, using (VOID *) typedefs for opaque handles is a tragic
mistake in all of the UEFI-related specifications; this practice defeats
any type checking that compilers might help programmers with. The right
way to define an opaque handle is as follows:
//
// Introduce the incomplete structure type, and the derived pointer
// type, in both the specification and the public edk2 headers. Note
// that the derived pointer type itself is a complete type, and it can
// be used freely by client code.
//
typedef struct SHELL_FILE *SHELL_FILE_HANDLE;
//
// Complete the structure type in the edk2 internal C source files.
//
struct SHELL_FILE {
//
// list fields
//
};
This way the structure size and members remain hidden from client code,
but the C compiler can nonetheless catch any invalid conversions between
incompatible XXX_HANDLE types.
Jiewen Yao [Wed, 15 Mar 2017 09:23:46 +0000 (17:23 +0800)]
MdePkg/dsc: add SmmIoLib
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Jiewen Yao [Wed, 15 Mar 2017 09:24:31 +0000 (17:24 +0800)]
MdePkg/dec: Add SmmIoLib.
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Jiewen Yao [Wed, 15 Mar 2017 09:23:20 +0000 (17:23 +0800)]
MdePkg/SmmIoLib: Add sample instance.
The sample instance check if IO resource is valid
one defined in GCD.
A platform may choose add more check to exclude some
other IO resource.
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Jiewen Yao [Wed, 15 Mar 2017 09:23:01 +0000 (17:23 +0800)]
MdePkg/SmmIoLib: Add header file.
This SmmIoLib is used to check if an IO resource
is valid in SMM.
Cc: Jeff Fan <jeff.fan@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Jeff Fan [Fri, 21 Apr 2017 03:00:59 +0000 (11:00 +0800)]
UefiCpuPkg/MpInitLib: needn't to allocate AP reset vector
Because we will always borrow the AP reset vector space for AP waking up. We
needn't allocate such range to prevent other module to use it. It could simply
the code.
Jeff Fan [Wed, 19 Apr 2017 03:16:55 +0000 (11:16 +0800)]
UefiCpuPkg/MpInitLib: save/restore original contents
If APs is in HLT-LOOP mode, we need AP reset vector for waking up APs. This
updating is to save/restore original contents of AP reset vector around waking
up APs always.
Jeff Westfahl [Fri, 21 Apr 2017 21:25:07 +0000 (05:25 +0800)]
ShellPkg SmbiosView: Display Type 0 BIOS segment in hexadecimal
The SMBIOS Type 0 BIOS segment field is currently displayed in decimal.
Since this field is likely to have a value like 0xE800 or 0xF000, using
hexadecimal seems like a better choice.
Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Jaben Carsey <jaben.carsey@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeff Westfahl <jeff.westfahl@ni.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
MdeModulePkg/NvmExpressDxe: Handling return of write to sq and cq db
In case of an async command if updating the submission queue tail
doorbell fails then the command will not be picked up by device and
no completion response will be created. This scenario has to be handled.
Also if we create an AsyncRequest element and insert in the async queue,
it will never receive a completion so in the timer routine this element
won't be freed, resulting in memory leak. Also in case of blocking calls
we should capture the status of updating completion queue head doorbell
register and return it to caller of PassThru.
MdeModulePkg/DeviceManagerUiLib: Fix the network device MAC display issue
v3:
* Add NULL string check.
v2:
* Define new STR_FORM_NETWORK_DEVICE_TITLE_HEAD for L" Network Device "
instead of hard code in the code.
Network device tile (STR_FORM_NETWORK_DEVICE_TITLE) is dynamic adjusted
according the different MAC value. So, the string value shouldn't be treated
as a constant string (Network Device). Otherwise, the display will be
incorrect.
Reproduce: Device Manager->Network Device List, select to enter MAC, then to
press ESC back to previous page, then re-enter, found each enter/ESC operation,
the MAC address display +1.
Cc: Eric Dong <eric.dong@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: Ye Ting <ting.ye@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
NetworkPkg/TlsAuthConfigDxe: Close and free the file related resource
v2:
* Define one new internal function to clean the file content.
TlsAuthConfigDxe open file by FileExplorerLib. It need to close
file handler and free file related resource in some cases.
* User enrolls Cert by escape the Config page.
* The Cert is not X509 type.
* User chooses another file after he selected a file.
Cc: Zhang Chao B <chao.b.zhang@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: Chao Zhang<chao.b.zhang@intel.com>
When PXE10/WFM11a offer received, we should only cache
the first PXE10/WFM11a offer, and discard the others. But
Current we discard all PXE10/WFM11a offer. This patch is
to fix this issue.
Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Zhang Lubo <lubo.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
Ruiyu Ni [Wed, 19 Apr 2017 09:16:27 +0000 (17:16 +0800)]
MdeModulePkg/UefiBootManagerLib: Avoid buggy USB short-form expanding
When a load option points to a physical UsbIo controller, whose
device path contains UsbClass or UsbWwid node, old logic
unconditionally treats it as a short-form device path and expands
it. But the expanding gets the exactly same device path, and the
device path is passed to BmGetNextLoadOptionDevicePath() which
then passes this device path to BmExpandUsbDevicePath() again.
This causes a infinite recursion.
The patch avoids the USB short-form expanding when the device path
points to a physical UsbIo controller.
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Feng Tian <feng.tian@intel.com> Reviewed-by: Jeff Fan <jeff.fan@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Michael Turner <Michael.Turner@microsoft.com>
NetworkPkg: Fix bug related DAD issue in IP6 driver.
If we set PXEv6 as the first boot option and reboot immediately
after the first successful boot, it will assert. the root cause is
when we set the policy from manual to automatic in PXE driver,
the ip6 Configure item size is already set to zero and other
structures are also released, So it is not needed to perform DAD call
back function which is invoked by Ip6ConfigSetMaunualAddress.
Star Zeng [Wed, 19 Apr 2017 03:12:18 +0000 (11:12 +0800)]
MdeModulePkg PiSmmCore: Enhance SMM FreePool to catch buffer overflow
This solution is equivalent to DXE core.
AllocatePool() allocates POOL_TAIL after the buffer.
This POOL_TAIL is checked at FreePool().
If the there is buffer overflow, the issue can be caught at FreePool().
This patch could also handle the eight-byte aligned allocation
requirement. The discussion related to the eight-byte aligned
allocation requirement is at
https://lists.01.org/pipermail/edk2-devel/2017-April/009995.html.
According to the PI spec (Vol 4, Section 3.2 SmmAllocatePool()):
The SmmAllocatePool() function ... All allocations are eight-byte aligned.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Hao Wu <hao.a.wu@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> Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Hao Wu [Tue, 21 Mar 2017 05:22:36 +0000 (13:22 +0800)]
MdeModulePkg/Ufs: Wait fDeviceInit be cleared by devices during init
In the origin codes, the host sets the fDeviceInit flag to initiate device
initialization, but does not check whether the device resets this flag
to indicate the device initialization is completed.
Details can be referred at UFS 2.0 Spec Section 14.2 - Flags.
projects / mirror_edk2.git / log